On Thu, 2024-07-04 at 00:54 +0800, Xi Ruoyao wrote: > On Wed, 2024-07-03 at 09:31 -0700, Linus Torvalds wrote: > > On Wed, 3 Jul 2024 at 01:46, Christian Brauner <brauner@xxxxxxxxxx> > > wrote: > > > > > > We've now added AT_EMPTY_PATH support with NULL names because we > > > want to > > > allow that generically. But I clearly remember that this was > > > requested > > > to make statx() work with these sandboxes. So the kernel has done > > > its > > > part. Now it's for the sandbox to allow statx() with NULL paths and > > > AT_EMPTY_PATH but certainly not for the kernel to start reenabling > > > old > > > system calls. > > > > Those old system calls are still used. > > > > Just enable them. > > > > statx isn't the promised land. Existing applications matter. And there > > is absolutely nothing wrong with plain old 'stat' (well, we call it > > "newstat" in the kernel for historical reasons) on 64-bit > > architectures. > > > > Honestly, 'statx' is disgusting. I don't understand why anybody pushes > > that thing that nobody actually uses or cares about. > > Hmm why it was added in the first place then? Why not just NAK it? If > someone tries to add a "seccomp sandbox" into my project I'll > immediately NAK it anyway :). > > And should we add stat_time64, fstat_time64, and fstatat_time64 to stop > using statx on 32-bit platforms too as it's disgusting? > > Also some bad news: Glibc has this: > > #if (__WORDSIZE == 32 \ > && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32)) \ > || defined STAT_HAS_TIME32 \ > || (!defined __NR_newfstatat && !defined __NR_fstatat64) > # define FSTATAT_USE_STATX 1 > #else > # define FSTATAT_USE_STATX 0 > #endif > > So if a LoongArch Glibc is built with Linux kernel headers >= 6.11, > it'll use fstatat **even configured --with-kernel=5.19** and fail to run > on Linux kernel <= 6.10. This will immediately blow up building Linux > From Scratch on a host distro with an "old" kernel. > > <sarcasm>Alright, some Google project matters but Glibc does not matter > because it uses a disgusting syscall in the first place.</sarcasm> > > We have to add some __ASSUME_blah_blah here now. > > To make things worse Glibc 2.40 is being frozen today :(. Copying to > libc-alpha and the RM. Alright it's not an emergency issue. It will only blow up when we run update-syscall-lists.py the next time. Thus this release should be OK and I'm going to lying flat for now. -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
