From: "Michael Kerrisk (man-pages)" <email@example.com>
To: Aleksa Sarai <firstname.lastname@example.org>
Cc: Thadeu Lima de Souza Cascardo <email@example.com>,
Linux API <firstname.lastname@example.org>,
Ingo Molnar <email@example.com>,
Arnaldo Carvalho de Melo <firstname.lastname@example.org>,
Jiri Olsa <email@example.com>,
Patrick Bellasi <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>,
Michael Kerrisk <email@example.com>
Subject: Re: [PATCH] sched_getattr.2: update to include changed size semantics
Date: Sat, 25 Apr 2020 21:12:15 +0200 [thread overview]
Message-ID: <CAKgNAkj9W7ay+YuQv1ct+LXE8tj1R+hzDDgGZo3KvWhWD0k2ug@mail.gmail.com> (raw)
I don't think there was ever a follow-up to this patch. Would you be
willing to send one?
On Thu, 28 Nov 2019 at 14:55, Aleksa Sarai <firstname.lastname@example.org> wrote:
> On 2019-11-28, Thadeu Lima de Souza Cascardo <email@example.com> wrote:
> > On Thu, Nov 28, 2019 at 11:01:40PM +1100, Aleksa Sarai wrote:
> > > Due to a userspace breakage, commit 1251201c0d34 ("sched/core: Fix
> > > uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and
> > > code") changed the semantics of sched_getattr(2) when the userspace
> > > struct is smaller than the kernel struct. Now, any trailing non-zero
> > > data in the kernel structure is ignored when copying to userspace.
> > >
> > > Ref: 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
> > > robustify sched_read_attr() ABI logic and code")
> > > Signed-off-by: Aleksa Sarai <firstname.lastname@example.org>
> > > ---
> > > man2/sched_setattr.2 | 6 ++----
> > > 1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/man2/sched_setattr.2 b/man2/sched_setattr.2
> > > index 76ffa14eba85..fbb67b8eb98b 100644
> > > --- a/man2/sched_setattr.2
> > > +++ b/man2/sched_setattr.2
> > > @@ -284,10 +284,8 @@ structure,
> > > the additional bytes in the user-space structure are not touched.
> > > If the caller-provided structure is smaller than the kernel
> > > .I sched_attr
> > > -structure and the kernel needs to return values outside the provided space,
> > > -.BR sched_getattr ()
> > > -fails with the error
> > > -.BR E2BIG .
> > > +structure, the kernel will silently not return any values which would be stored
> > > +outside the provided space.
> > > As with
> > > .BR sched_setattr (),
> > > these semantics allow for future extensibility of the interface.
> > > --
> > > 2.24.0
> > >
> > I was thinking about documenting the difference in behavior of older kernels,
> > before uclamp support.
> > However, in practice, for sched_getattr, the kernel never returned E2BIG (the
> > code uses EFBIG incorrectly, in fact). It does, however, return EINVAL for
> > sizes smaller than SCHED_ATTR_SIZE_VER0.
> I've been told the EFBIG was actually a typo and it was always meant to
> be E2BIG. But yes, the precise problem with the old semantics was that
> they weren't tested "in the wild" with a proper struct upgrade -- hence
> all of the headaches.
> If we ever do implement a copy_struct_to_user() we are almost certainly
> going to implement it with the new sched_getattr() semantics. To be
> honest, I'm not sure I can imagine a case where an old userspace program
> would benefit from being given an error saying that the kernel has some
> properties that it doesn't understand. (sched_getattr() is also weird
> for other reasons, such as the fact it takes a separate size argument.)
> > However, E2BIG is still mentioned below as a possible return value for
> > sched_getattr. Can you remove that too?
> Will do.
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2020-04-25 19:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 12:01 [PATCH] sched_getattr.2: update to include changed size semantics Aleksa Sarai
2019-11-28 13:08 ` Thadeu Lima de Souza Cascardo
2019-11-28 13:55 ` Aleksa Sarai
2020-04-25 19:12 ` Michael Kerrisk (man-pages) [this message]
2020-05-15 12:10 ` Michael Kerrisk (man-pages)
2020-09-29 22:35 ` [PATCH 1/2] " Aleksa Sarai
2020-09-29 22:35 ` [PATCH 2/2] openat2.2: fix minor reference typo Aleksa Sarai
2020-09-30 10:51 ` Michael Kerrisk (man-pages)
2020-09-30 10:51 ` [PATCH 1/2] sched_getattr.2: update to include changed size semantics Michael Kerrisk (man-pages)
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.