[PATCH 0/3] Add the sched_setattr, sched_getattr functions

[enh]

On Thu, Sep 5, 2024 at 4:39 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> > On Thu, Sep 5, 2024 at 3:51 PM Carlos O'Donell <carlos@redhat.com> wrote:
> >>
> >> On 9/5/24 2:33 PM, Florian Weimer wrote:
> >> > These are straightforward system call wrappers.  Like the existing
> >> > sched_* scheduler policy functions, sched_setattr interacts poorly with
> >> > PTHREAD_PRIO_PROTECT mutexes.
> >>
> >> As noted by Jopseh Myers in 2015, these interfaces should have had wrappers
> >> a long time ago following:
> >> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
> >>
> >> I think these APIs meet the goals outlined there, modulo their poor interaction
> >> with the pthread_* APIs, which is something that can be improved over time.
> >
> > do you trust upstream not to break source compatibility again? there
> > have already been two different versions of this struct with the same
> > name. or are you just assuming that next time they do it, userspace
> > has a struct sched_attr_2?
>
> The v2 patch has some additional explanation how the extensibility is
> expected to work:
>
>   [PATCH v2 2/3] Linux: Add the sched_setattr and sched_getattr functions
>   <https://inbox.sourceware.org/libc-alpha/1f7f9c80017e91f0af99e1bfd9ec1f59c6cc0da7.1725567796.git.fweimer@redhat.com/>
>
> It's fairly standard as far as such interfaces go, I think.

oh, interesting ... do you have example precedent there? (in
particular i'm wondering whether i'm just blanking on other places
where this has happened in bionic, or whether the most recent examples
pre-date Android/only affected architectures Android doesn't support?)

> > btw, from my [machine-readable seccomp] notes, here's a couple of
> > other similarly old syscalls glibc's missing:
> >
> > # Since Linux 4.3, not in glibc. Probed for and conditionally used by ART.
> > int membarrier(int, int) all
> > int userfaultfd(int) all
>
> Well, membarrier started out with just two arguments, and now it's using
> three.

even more weird then that musl has the wrapper!

> I suspect it's going to cause more trouble for us than
> sched_setattr/sched_getattr.

maybe. i should perhaps have said that i _started_ doing the
sched_setattr()/sched_getattr() work in bionic but found that it broke
a bunch of stuff. iirc it was specifically the combination of
"everyone has had to polyfill this" and "...but there have been two
versions" that made it a pain.

> Thanks,
> Florian
>