On Mon, 2024-02-26 at 10:20 +0100, Arnd Bergmann wrote:

/* snip */

quoted

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 */

quoted

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 [off-list ref]
School of Aerospace Science and Technology, Xidian University