Re: [RFC][PATCH 10/13] get rid of audit_reusename()

[Mateusz Guzik <mjguzik@gmail.com>]

On Sun, Nov 9, 2025 at 8:18 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sat, 8 Nov 2025 at 22:38, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > These days we have very few places that import filename more than once
> > (9 functions total) and it's easy to massage them so we get rid of all
> > re-imports.  With that done, we don't need audit_reusename() anymore.
> > There's no need to memorize userland pointer either.
>
> Lovely. Ack on the whole series.
>
> I do wonder if we could go one step further, and try to make the
> "struct filename" allocation rather much smaller, so that we could fit
> it on the stack,m and avoid the whole __getname() call *entirely* for
> shorter pathnames.
>
> That __getname() allocation is fairly costly, and 99% of the time we
> really don't need it because audit doesn't even get a ref to it so
> it's all entirely thread-local.
>

I looked into this in the past, 64 definitely does not cut it. For
example take a look at these paths from gcc:
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/lib/../lib/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/12/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/Scrt1.o

Anyhow, given that the intent is to damage-control allocation cost, I
have to point out there is a patchset to replace the current kmem
alloc/free code with sheaves for everyone which promises better
performance:
https://lore.kernel.org/linux-mm/20251023-sheaves-for-all-v1-0-6ffa2c9941c0@suse.cz/

I tried it and there is some improvement, but the allocator still
remains as a problem. Best case scenario sheaves code just gets better
and everyone benefits.

However, so happens I was looking at this very issue recently and I
suspect the way forward is to handroll a small per-cpu cache from
kmalloced memory. Items would be put there and removed protected by
preemption only, so it should be rather cheap without any of the
allocator boiler-plate. The bufs could be -- say -- 512 bytes in size
and would still be perfectly legal to hand off to audit as they come.
The question is how many paths need to be cached to avoid going to the
real allocator in practice -- too many would invalidate the idea.