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

[Florian Weimer]

> 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.

> 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.  I suspect it's going to cause more trouble for us than
sched_setattr/sched_getattr.

Thanks,
Florian