On Sun, Jun 30, 2024 at 10:40 AM Xi Ruoyao <xry111@xxxxxxxxxxx> wrote: > > On Sun, 2024-06-30 at 09:40 +0800, Huacai Chen wrote: > > On Tue, Jun 25, 2024 at 11:00 PM Xi Ruoyao <xry111@xxxxxxxxxxx> wrote: > > > > > > On Tue, 2024-06-25 at 22:09 +0800, Huacai Chen wrote: > > > > On Tue, Jun 25, 2024 at 7:01 PM Mateusz Guzik <mjguzik@xxxxxxxxx> > > > > wrote: > > > > > > > > > > The newly used helper also checks for 0-sized buffers. > > > > > > > > > > This avoids path lookup code, lockref management, memory > > > > > allocation > > > > > and > > > > > in case of NULL path userspace memory access (which can be quite > > > > > expensive with SMAP on x86_64). > > > > > > > > > > statx with AT_EMPTY_PATH paired with "" or NULL argument as > > > > > appropriate > > > > > issued on Sapphire Rapids (ops/s): > > > > > stock: 4231237 > > > > > 0-check: 5944063 (+40%) > > > > > NULL path: 6601619 (+11%/+56%) > > > > > > > > > > Signed-off-by: Mateusz Guzik <mjguzik@xxxxxxxxx> > > > > Hi, Ruoyao, > > > > > > > > I'm a bit confused. Ii this patch a replacement of your recent > > > > patch? > > > > > > Yes, both Linus and Christian hates introducing a new AT_ flag for > > > this. > > > > > > This patch just makes statx(fd, NULL, AT_EMPTY_PATH, ...) behave > > > like > > > statx(fd, "", AT_EMPTY_PATH, ...) instead. NULL avoids the > > > performance > > > issue and it's also audit-able by seccomp BPF. > > To be honest, I still want to restore __ARCH_WANT_NEW_STAT. Because > > even if statx() becomes audit-able, it is still blacklisted now. > > Then patch the sandbox to allow it. > > The sandbox **must** be patched anyway or it'll be broken on all 32-bit > systems after 2037. [Unless they'll unsupport all 32-bit systems before > 2037.] Yes, but it will not happen immediately. > > > Restoring __ARCH_WANT_NEW_STAT is a very small change that doesn't > > introduce any complexity, but it makes life easier. And I think libLoL > > also likes __ARCH_WANT_NEW_STAT, though it isn't an upstream > > project... > > At least you should not restore it for 32-bit. libLoL also has nothing > to do with 32-bit systems anyway. Maybe conditional it with a #if > checking __BITS_PER_LONG. Agree, but currently LoongArch only support 64bit, so we don't need #ifdef now (Many Kconfig options also need to depend on 64bit, but dependencies are removed when LoongArch get upstream). > > And the vendors should really port their software to the upstreamed ABI > instead of relying on liblol. <rant>Is a recompiling so difficult, or > are the programmers so stupid to invoke plenty of low-level syscalls > directly (bypassing Glibc) in their code?</rant> Unfortunately, libLoL may exist for a very long time. Recompiling isn't difficult, the real problem is "I have already ported to LoongArch, why should I port again?". Huacai > > -- > Xi Ruoyao <xry111@xxxxxxxxxxx> > School of Aerospace Science and Technology, Xidian University >
