Re: [PATCH] fs: Keep long filenames in isolated slab buckets

[Al Viro <viro@zeniv.linux.org.uk>]

On Wed, Feb 11, 2026 at 03:06:47AM +0100, Jann Horn wrote:

> > > I think this path, where we always do maximally-sized allocations, is
> > > the normal case where we're handling paths coming from userspace...
> >
> > Actually, is there any reason we can't use strnlen_user() in
> > do_getname(), and then just use strndup_user() in the long case?
> 
> I'm not an expert, but as far as I know, this path is supposed to be
> really fast (because pretty much every syscall that operates on a path
> will hit it), and doesn't care how much memory it allocates (because
> these allocations are normally only alive for the duration of a
> syscall). strnlen_user() would add another pass over the userspace
> buffer, which I think would probably have negative performance impact?

Sigh...  This is the case of path longer than 168 bytes (EMBEDDED_NAME_MAX);
that's not hard to trigger, but not exactly common.  What matters more is
that we really do not want to deal with the "now it appears to be empty"
case here - it makes the logics in the caller more convoluted and it's not
pretty as it is.

And no, it is not going to be presistent - the longest you can stick such
beasts in there is probably with io-uring; names copied in when request is
submitted and stay around until a worker thread gets around to finishing
the request.