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

[Mateusz Guzik <mjguzik@gmail.com>]

On Sun, Nov 9, 2025 at 9:22 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, 9 Nov 2025 at 11:55, Mateusz Guzik <mjguzik@gmail.com> wrote:
> >
> > I looked into this in the past, 64 definitely does not cut it.
>
> We could easily make it be 128 bytes, I just picked 64 at random.
>

I see I neglected to mention, the lengths I had seen were untenable
for a stack-based allocation. Going with a smaller on-stack buf means
having to retry with an extra SMAP trip which probably makes it a
no-go.

While I can't easily redo the survey on Linux, here is a taste from 10
minutes of package building on FreeBSD. A histogram of lengths with a
step of 8, rounded down.

You would need 256 bytes to cover almost all of this. Maybe 192-ish is
a bare minimum where the idea is likely a win? But even then the
people who want 8K stacks probably wont be able to use the feature to
begin with.

dtrace -n 'vfs:namei:lookup:entry { @ =
lquantize(strlen(stringof(arg1)), 0, 384, 8); }'

 value  ------------- Distribution ------------- count
             < 0 |                                         0
               0 |@@@@@@@@                                 18105105
               8 |@@@@@@@                                  16360012
              16 |@@@@@@@@@                                21313430
              24 |@@@@@@                                   15000426
              32 |@@@                                      6450202
              40 |@@                                       4209166
              48 |@                                        2533298
              56 |@                                        1611506
              64 |@                                        1203825
              72 |                                         1068207
              80 |                                         877158
              88 |                                         592192
              96 |                                         489958
             104 |                                         709757
             112 |                                         925775
             120 |                                         1041627
             128 |@                                        1315123
             136 |                                         664687
             144 |                                         276673
             152 |                                         150870
             160 |                                         82661
             168 |                                         40630
             176 |                                         26693
             184 |                                         15112
             192 |                                         7276
             200 |                                         5773
             208 |                                         2462
             216 |                                         1679
             224 |                                         1150
             232 |                                         1301
             240 |                                         1652
             248 |                                         659
             256 |                                         464
             264 |                                         0


> > 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:
>
> Oh, I'm sure sheaves will improve on the allocation path, but it's not
> going to be even remotely near what a simple stack allocation will be.
> Not just from an allocation cost standpoint, but just from D$ density.
>

I completely agree, but per the above the sizes look unwieldy for the
stack. This is something I tried to do years back and backed off due
to that reason.

> That said, I partly like my patch just because the current code in
> getname_flags() is simply disgusting for all those historical reasons.
> So even if we kept the allocation big - and didn't put it on the stack
> - I think actually using a proper 'struct filename' allocation would
> be a good change.
>

I don't know of anyone is fond of the current code. ;)