Re: Update syscall lists for Linux 5.19

[Palmer Dabbelt <palmer@dabbelt.com>]

On Fri, 05 Aug 2022 14:44:42 PDT (-0700), aurelien@aurel32.net wrote:
> On 2022-08-05 10:28, Palmer Dabbelt wrote:
>> On Fri, 05 Aug 2022 07:42:48 PDT (-0700), aurelien@aurel32.net wrote:
>> > On 2022-08-03 17:36, Palmer Dabbelt wrote:
>> > > On Tue, 02 Aug 2022 12:23:42 PDT (-0700), joseph@codesourcery.com wrote:
>> > > > Linux 5.19 has no new syscalls, but enables memfd_secret in the uapi
>> > > > headers for RISC-V.  Update the version number in syscall-names.list
>> > > > to reflect that it is still current for 5.19 and regenerate the
>> > > > arch-syscall.h headers with build-many-glibcs.py update-syscalls.
>> > > >
>> > > > Tested with build-many-glibcs.py.
>> > > >
>> > > > diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h b/sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h
>> > > > index bf4be80..202520e 100644
>> > > > --- a/sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h
>> > > > +++ b/sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h
>> > > > @@ -122,6 +122,7 @@
>> > > >  #define __NR_mbind 235
>> > > >  #define __NR_membarrier 283
>> > > >  #define __NR_memfd_create 279
>> > > > +#define __NR_memfd_secret 447
>> > > >  #define __NR_migrate_pages 238
>> > > >  #define __NR_mincore 232
>> > > >  #define __NR_mkdirat 34
>> > > > diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/arch-syscall.h b/sysdeps/unix/sysv/linux/riscv/rv64/arch-syscall.h
>> > > > index d656aed..4e65f33 100644
>> > > > --- a/sysdeps/unix/sysv/linux/riscv/rv64/arch-syscall.h
>> > > > +++ b/sysdeps/unix/sysv/linux/riscv/rv64/arch-syscall.h
>> > > > @@ -127,6 +127,7 @@
>> > > >  #define __NR_mbind 235
>> > > >  #define __NR_membarrier 283
>> > > >  #define __NR_memfd_create 279
>> > > > +#define __NR_memfd_secret 447
>> > > >  #define __NR_migrate_pages 238
>> > > >  #define __NR_mincore 232
>> > > >  #define __NR_mkdirat 34
>> > > > diff --git a/sysdeps/unix/sysv/linux/syscall-names.list b/sysdeps/unix/sysv/linux/syscall-names.list
>> > > > index 6c7b2f7..028ad31 100644
>> > > > --- a/sysdeps/unix/sysv/linux/syscall-names.list
>> > > > +++ b/sysdeps/unix/sysv/linux/syscall-names.list
>> > > > @@ -21,8 +21,8 @@
>> > > >  # This file can list all potential system calls.  The names are only
>> > > >  # used if the installed kernel headers also provide them.
>> > > >
>> > > > -# The list of system calls is current as of Linux 5.18.
>> > > > -kernel 5.18
>> > > > +# The list of system calls is current as of Linux 5.19.
>> > > > +kernel 5.19
>> > > >
>> > > >  FAST_atomic_update
>> > > >  FAST_cmpxchg
>> > >
>> > > Thanks, this was just a bug in the uapi headers: the syscall itself was has
>> > > been implemented since 7bb7f2ac24a0 ("arch, mm: wire up memfd_secret system
>> > > call where relevant"), which IIUC was first released in 5.14.  The fix
>> > > should get backported.
>> >
>> > It got backported in 5.18.3.
>>
>> Sorry if that was the wrong thing to do, I thought this was safe because it
>> was just making the number availiable in the headers.
>>
>> > > I don't think any of that matters so much here, though.
>> >
>> > The backport causes the misc/tst-glibcsyscalls test to fail on the
>> > stable branches (tested on 2.35, but I guess it's the same on 2.36):
>> >
>> > | original exit status 1
>> > | error: kernel syscall 'memfd_secret' (447) not known to glibc
>> > | info: glibc tables are based on kernel version 5.18
>> > | info: installed kernel headers are version 5.18
>> >
>> > So I wonder if we should just backport this commit to the stable
>> > branches to fix this failure.
>>
>> That works for me.  Another option would be to revert the backport in Linux.
>> Either way we're stuck with some combination of releases that fail, so I'm
>> not sure which is better.
>
> No I do not think it is so bad. Errors are only reported when glibc
> headers version >= kernel version (otherwise they are just warnings). So
> if we increase glibc headers version to 5.18 by backporting this patch,
> they won't be errors anymore with kernel headers 5.18.y or older.

OK, thanks.  I'll try to remember this in case it happens again.