From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] timer_create01: accept kernel ENOTSUPP
Date: Wed, 23 Oct 2019 14:50:31 -0300 [thread overview]
Message-ID: <20191023175030.GE4055@calabresa> (raw)
In-Reply-To: <20191023153631.GA12897@rei>
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
prev parent reply other threads:[~2019-10-23 17:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 13:56 [LTP] [PATCH] timer_create01: accept kernel ENOTSUPP Jan Stancek
2019-10-23 13:58 ` Jan Stancek
2019-10-23 14:03 ` Cyril Hrubis
2019-10-23 14:04 ` Thadeu Lima de Souza Cascardo
2019-10-23 14:29 ` Martin Doucha
2019-10-23 14:35 ` Cyril Hrubis
2019-10-23 14:56 ` Thadeu Lima de Souza Cascardo
2019-10-23 15:36 ` Cyril Hrubis
2019-10-23 15:38 ` Cyril Hrubis
2019-10-23 17:50 ` Thadeu Lima de Souza Cascardo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191023175030.GE4055@calabresa \
--to=cascardo@canonical.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.