Re: [PATCH] 9p: dynamically allocate directory entry names

[Dominique Martinet <asmadeus@codewreck.org>]

Jan Kara wrote on Wed, Sep 16, 2026 at 11:47:00AM +0200:
> On Mon 14-09-26 00:12:25, Dominique Martinet wrote:
> > +fsdevel@ & vfs maintainers to Cc TL;DR:
> > Should the 9p .iterate_shared() dir_emit files with path
> > components > NAME_LEN, as allowed in fs/readdir.c verify_dirent_name()
> > only enforcing length < PATH_MAX, or should we skip any such entry given
> > nothing can interact with them later anyway?
> 
> So my take on this is that I'd refuse any entries larger than NAME_MAX
> (255). As you say it is very likely something in userspace or other parts
> of the kernel (fs drivers, ...) will break with such names so I don't think
> there's a good reason to provoke these bugs. For example POSIX states
> readdir(2) should be returning component of at most NAME_MAX length and
> although we don't take POSIX very seriously in the kernel in this case I
> don't think there's a good enough reason to deviate from it.

Thanks for taking the time to confirm this! Let's go with that direction
then.


@hoobnn: as said in my previous mail I can't take your patch unless you
give me a name, but the idea behind the patch is trivial so if I don't
hear back from you in say ~2 weeks I'll send a patch under my name that
reimplements what you did, plus check the strlen() result that's already
done in v9fs_dir_readdir_dotl() so entries > NAME_MAX are skipped over.

If you reply then there's no hurry on my end and you can take your time,
please send a v2 of this as two patches, one skipping the extra copy
into p9_dirent as done here and one for the limit

-- 
Dominique