From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] timer_create01: accept kernel ENOTSUPP
Date: Wed, 23 Oct 2019 17:36:31 +0200 [thread overview]
Message-ID: <20191023153631.GA12897@rei> (raw)
In-Reply-To: <20191023145640.GD4055@calabresa>
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
next prev parent reply other threads:[~2019-10-23 15:36 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 [this message]
2019-10-23 15:38 ` Cyril Hrubis
2019-10-23 17:50 ` Thadeu Lima de Souza Cascardo
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=20191023153631.GA12897@rei \
--to=chrubis@suse.cz \
--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.