Loongarch: adapt for the re-introduction of fstat and newfstatat in 6.11

From: Miao Wang <shankerwangmiao@gmail.com>

In Linux 6.11, fstat and newfstatat are added back. We need to include
this change in kernel-features.h to avoid producing libraries
incompatible with previous linux versions with new headers.

The defination of the two syscalls will be removed when the targeted
kernel version is below 6.11 in loongarch/sysdep.h.

Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
Kernel 6.11 adds back fstat and newfstatat in commit 7697a0fe0154
("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h"). With kernel
headers from 6.11, make update-syscall-lists will generate the following
diffs:


---
base-commit: 2eee835eca960c9d4119279804214b7a1ed5d156
change-id: 20240820-loong-fstat-f57f8be48575

Best regards,

On Tue, 2024-08-20 at 20:27 +0800, Miao Wang via B4 Relay wrote:

> Kernel 6.11 adds back fstat and newfstatat in commit 7697a0fe0154
> ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h"). With kernel
> headers from 6.11, make update-syscall-lists will generate the following
> diffs:
> 
> diff --git a/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h b/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h

Don't directly embed a diff here (w/o some mangling).  Doing so will
puzzle patchwork, git am, etc to consider it a part of the patch.  Look
at the unwanted effect at
https://patchwork.sourceware.org/project/glibc/patch/20240820-loong-fstat-v1-1-799b6627bb2f@gmail.com/.

> +#include_next <kernel-features.h>
> +
> +#define __ASSUME_LOONGARCH_NEWSTAT 1
> +
> +/* No support for fstat or newfstatat before 6.11.  */

6.10.6, the change is backported so we can assume anything >= 6.10.6
have these syscalls.  But we cannot make a reasonable assumption with
other backports like 6.6.47.

> +#if __LINUX_KERNEL_VERSION < 0x060b00

0x060a06.

> +# undef __ASSUME_LOONGARCH_NEWSTAT

Can we just #undef __NR_fstat and #undef __NR_newfstatat here?  Sparc is
undefining __NR_pause in their kernel-features.h.

> +#endif

The email address of Joseph was outdated.  I got a bounce from
mentor.com.

On Tue, 2024-08-20 at 20:44 +0800, Xi Ruoyao wrote:
> On Tue, 2024-08-20 at 20:27 +0800, Miao Wang via B4 Relay wrote:
> 
> > Kernel 6.11 adds back fstat and newfstatat in commit 7697a0fe0154
> > ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h"). With kernel
> > headers from 6.11, make update-syscall-lists will generate the
> > following
> > diffs:
> > 
> > diff --git a/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h
> > b/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h
> 
> Don't directly embed a diff here (w/o some mangling).  Doing so will
> puzzle patchwork, git am, etc to consider it a part of the patch. 
> Look
> at the unwanted effect at
> https://patchwork.sourceware.org/project/glibc/patch/20240820-loong-fstat-v1-1-799b6627bb2f@gmail.com/
> .
> 
> > +#include_next <kernel-features.h>
> > +
> > +#define __ASSUME_LOONGARCH_NEWSTAT 1
> > +
> > +/* No support for fstat or newfstatat before 6.11.  */
> 
> 6.10.6, the change is backported so we can assume anything >= 6.10.6
> have these syscalls.  But we cannot make a reasonable assumption with
> other backports like 6.6.47.
> 
> > +#if __LINUX_KERNEL_VERSION < 0x060b00
> 
> 0x060a06.
> 
> > +# undef __ASSUME_LOONGARCH_NEWSTAT
> 
> Can we just #undef __NR_fstat and #undef __NR_newfstatat here?  Sparc
> is
> undefining __NR_pause in their kernel-features.h.
> 
> > +#endif
>

Thanks for your quick reply.

> 2024年8月20日 20:46，Xi Ruoyao <xry111@xry111.site> 写道：
> 
> The email address of Joseph was outdated.  I got a bounce from
> mentor.com.
> 
> On Tue, 2024-08-20 at 20:44 +0800, Xi Ruoyao wrote:
>> On Tue, 2024-08-20 at 20:27 +0800, Miao Wang via B4 Relay wrote:
>> 
>>> Kernel 6.11 adds back fstat and newfstatat in commit 7697a0fe0154
>>> ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h"). With kernel
>>> headers from 6.11, make update-syscall-lists will generate the
>>> following
>>> diffs:
>>> 
>>> diff --git a/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h
>>> b/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h
>> 
>> Don't directly embed a diff here (w/o some mangling).  Doing so will
>> puzzle patchwork, git am, etc to consider it a part of the patch. 
>> Look
>> at the unwanted effect at
>> https://patchwork.sourceware.org/project/glibc/patch/20240820-loong-fstat-v1-1-799b6627bb2f@gmail.com/
>> .
>> 
>>> +#include_next <kernel-features.h>
>>> +
>>> +#define __ASSUME_LOONGARCH_NEWSTAT 1
>>> +
>>> +/* No support for fstat or newfstatat before 6.11.  */
>> 
>> 6.10.6, the change is backported so we can assume anything >= 6.10.6
>> have these syscalls.  But we cannot make a reasonable assumption with
>> other backports like 6.6.47.
Actually such backport is questionable, since it changes the kernel feature.
I believe that this breaks our assumption that kernel will have certain feature
if version >= some number. So I think we can ignore the stable backports and
only focus on the mainline releases.
>> 
>>> +#if __LINUX_KERNEL_VERSION < 0x060b00
>> 
>> 0x060a06.
>> 
>>> +# undef __ASSUME_LOONGARCH_NEWSTAT
>> 
>> Can we just #undef __NR_fstat and #undef __NR_newfstatat here?  Sparc
>> is
>> undefining __NR_pause in their kernel-features.h.

I think it would be better if in sysdep.h. As far as I know, the inclusion
of headers orders like that:

  sysdeps/unix/sysv/linux/loongarch/sysdep.h
    sysdeps/unix/sysv/linux/sysdep.h
      sysdeps/unix/sysv/linux/loongarch/kernel-features.h
        sysdeps/unix/sysv/linux/kernel-features.h
    sysdeps/unix/sysdep.h
      sysdeps/unix/sysv/linux/include/sys/syscall.h
        sysdeps/unix/sysv/linux/loongarch/arch-syscall.h

So it seems to be safer to #undef in loongarch/sysdep.h after the inclusion
of sysdeps/unix/sysdep.h

Cheers,

Miao Wang     

>> 
>>> +#endif
>> 
> 
> -- 
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University

On Tue, 2024-08-20 at 21:03 +0800, Miao Wang wrote:
> > > > +/* No support for fstat or newfstatat before 6.11.  */
> > > 
> > > 6.10.6, the change is backported so we can assume anything >= 6.10.6
> > > have these syscalls.  But we cannot make a reasonable assumption with
> > > other backports like 6.6.47.
> Actually such backport is questionable, since it changes the kernel feature.
> I believe that this breaks our assumption that kernel will have certain feature
> if version >= some number. So I think we can ignore the stable backports and
> only focus on the mainline releases.

Why?  You cannot find an integer in (10, 11), thus any kernel release >=
6.10.6 will have these two syscalls, unless you plan to revert it for
6.10.7 or something.  And I cannot see how a revert is possible because
the ship is sailed and a revert will be outrageously "breaking
userspace" now.  If you really want to prevent it, you should have done
that before 6.10.6 release like I'd attempted to do (but nobody listened
to me).

Note that random kernel snapshots are not supported (i.e. 6.11.0-rc1
isn't considered a supported "release" between 6.10.6 and 6.11.0).  And
random non-Linus forks of the kernel aren't supported by Glibc as well
(for example, IA64 was directly removed from Glibc when the Linus' tree
removed IA64 despite some guys have a working non-Linus fork), so the
problematic vendor kernels mentioned by Greg and Cyril aren't ever
considered.

I'm now writing something in areweloongyet.com for this.  If we went
with 6.11.0 how would I explain the reason in the article?  Just
"someone thinks the backport is questionable"?  Then I think the
reintroduce of these two syscalls is questionable in the first place, so
should we never use them in Glibc?  Or for some reason your opinion can
make a difference but mine cannot?

OTOH it's a fact that any kernel release >= 6.10.6 supports those two
syscalls, so we should live with the fact (instead of opinions) and it's
the best way to avoid controversies.

> > > 
> > > > +#if __LINUX_KERNEL_VERSION < 0x060b00
> > > 
> > > 0x060a06.