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. 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. 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() was trying to avoid. Whichever solution we end up with should work on both loongarch64 and on armv7 at least. Arnd
