[LTP] [PATCH] timer_create01: accept kernel ENOTSUPP

[Thadeu Lima de Souza Cascardo]

On Wed, Oct 23, 2019 at 05:36:31PM +0200, Cyril Hrubis wrote:
> 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.
> 

So, if this is a matter of EOPNOTSUPP versus ENOTSUP (the userspace ones), then
the code that is applied to LTP uses ENOTSUP, which is what POSIX uses, so all
fine from the LTP standpoint.

To be honest, I am relieved about not getting to go through the process of
fixing this in the kernel once again.

Maybe we should even do the opposite and make clock_gettime and clock_getres
return ENOTSUP/EOPNOTSUPP.

Cascardo.

> -- 
> Cyril Hrubis
> chrubis@suse.cz