On Mon, 2024-02-26 at 07:56 +0100, Arnd Bergmann wrote: > On Mon, Feb 26, 2024, at 07:03, Icenowy Zheng wrote: > > 在 2024-02-25星期日的 15:32 +0800，Xi Ruoyao写道： > > > On Sun, 2024-02-25 at 14:51 +0800, Icenowy Zheng wrote: > > > > My idea is this problem needs syscalls to be designed with deep > > > > argument inspection in mind; syscalls before this should be > > > > considered > > > > as historical error and get fixed by resotring old syscalls. > > > > > > I'd not consider fstat an error as using statx for fstat has a > > > performance impact (severe for some workflows), and Linus has > > > concluded > > > > Sorry for clearance, I mean statx is an error in ABI design, not fstat. I'm wondering why we decided to use AT_EMPTY_PATH/"" instead of "AT_NULL_PATH"/nullptr in the first place? > The same has been said about seccomp(). ;-) > > It's clear that the two don't go well together at the moment. > > > > "if the user wants fstat, give them fstat" for the performance issue: > > > > > > https://sourceware.org/pipermail/libc-alpha/2023-September/151365.html > > > > > > However we only want fstat (actually "newfstat" in fs/stat.c), and it > > > seems we don't want to resurrect newstat, newlstat, newfstatat, etc. > > > (or > > > am I missing any benefit - performance or "just pleasing seccomp" - > > > of them comparing to statx?) so we don't want to just define > > > __ARCH_WANT_NEW_STAT. So it seems we need to add some new #if to > > > fs/stat.c and include/uapi/asm-generic/unistd.h. > > > > > > And no, it's not a design issue of all other syscalls. It's just the > > > design issue of seccomp. There's no way to design a syscall allowing > > > seccomp to inspect a 100-character path in its argument unless > > > refactoring seccomp entirely because we cannot fit a 100-character > > > path > > > into 8 registers. > > > > Well my meaning is that syscalls should be designed to be simple to > > prevent this kind of circumstance. But it's not irrational to pass a path to syscall, as long as we still have the concept of file system (maybe in 2371 or some year we'll use a 128-bit UUID instead of path). > The problem I see with the 'use use fstat' approach is that this > does not work on 32-bit architectures, unless we define a new > fstatat64_time64() syscall, which is one of the things that statx() "fstat64_time64". Using statx for fstatat should be just fine. Or maybe we can just introduce a new AT_something to make statx completely ignore pathname but behave like AT_EMPTY_PATH + "". > was trying to avoid. 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... > Whichever solution we end up with should work on both > loongarch64 and on armv7 at least. > > Arnd -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
