On Mon, 2024-02-26 at 10:20 +0100, Arnd Bergmann wrote: /* snip */ > > > Or maybe we can just introduce a new AT_something to make statx > > completely ignore pathname but behave like AT_EMPTY_PATH + "". > > I think this is better than going back to fstat64_time64(), but > it's still not great because > > - all the reserved flags on statx() are by definition incompatible > with existing kernels that return -EINVAL for any flag they do > not recognize. Oops, we are deeming passing undefined flags in "mask" undefined behavior but not "flags", thus "wild software" may be relying on EINVAL for invalid flags... We *might* make this new AT_xxx a bit in mask instead of flags but it would be very dirty IMO. > - you still need to convince libc developers to actually use > the flag despite the backwards compatibility problem, either > with a fallback to the current behavior or a version check. Let me ping some libc developers then... > Using the NULL path as a fallback would solve the problem with > seccomp, but it would not make the normal case any faster. But "wild software" may be relying on a EFAULT for NULL path too... /* snip */ > > > > Oops. I thought "newstat" should be using 64-bit time but it seems the > > "new" is not what I'd expected... The "new" actually means "newer than > > Linux 0.9"! :( > > > > Let's not use "new" in future syscall names... > > Right, we definitely can't ever succeed. On some architectures > we even had "oldstat" and "stat" before "newstat" and "stat64", > and on some architectures we mix them up. E.g. x86_64 has fstat() > and fstatat64() with the same structure but doesn't define > __NR_newfstat. On mips64, there is a 'newstat' but it has 32-bit > timestamps unlike all other 64-bit architectures. > > statx() was intended to solve these problems once and for all, > and it appears that we have failed again. https://xkcd.com/927/ :( -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
