Re: [PATCH 2/2] vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)

[Xi Ruoyao <xry111@xry111.site>]

On Sun, 2024-06-30 at 09:40 +0800, Huacai Chen wrote:
> On Tue, Jun 25, 2024 at 11:00 PM Xi Ruoyao <xry111@xry111.site> 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@gmail.com>
> > > 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@gmail.com>
> > > 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.]

> 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.

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>

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University