[LTP] [PATCH] timer_create01: accept kernel ENOTSUPP
Cyril Hrubis
chrubis@suse.cz
Wed Oct 23 17:36:31 CEST 2019
Hi!
> > Beware that kernel defines ENOTSUP that is not equal to EOPNOTSUPP and
> > in this case this value leaked to userspace leading to invalid userspace
> > errno value.
>
> That was ENOTSUPP (the internal kernel error, defined as 524). ENOTSUP, defined
> as EOPNOTSUPP, is the userspace error I guess Martin is saying should not be
> used either.
Ah, right, I misunderstand that.
> In that case, we need to fix the kernel to return EINVAL instead. Looking at
> older changes here, I see commit 98d6f4dd84a134d942827584a3c5f67ffd8ec35f
> ("alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist")
> claiming exactly this. Though it was about clock_getres and clock_gettime,
> quoting from that commit:
>
> "
> Second, Posix and Linux man pages agree that clock_gettime and
> clock_getres should return EINVAL if clk_id argument is invalid.
> While the arugment that the clockid is valid, but just not supported
> on this hardware could be made, this is just a technicality that
> doesn't help userspace applicaitons, and only complicates error
> handling.
> "
I would disagree, if you check latest POSIX it has:
[ENOTSUP]
The implementation does not support the creation of a timer attached
to the CPU-time clock that is specified by clock_id and associated
with a process or thread different from the process or thread
invoking timer_create().
https://pubs.opengroup.org/onlinepubs/9699919799/
So the implementation is required to return ENOTSUPP in certain cases
anyways so applying it to CLOCK_REALTIME_ALARM and
CLOCK_BOOTTIME_ALARM certainly makes sense.
--
Cyril Hrubis
chrubis@suse.cz
More information about the ltp
mailing list