From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: ericvh@kernel.org, lucho@ionkov.net, v9fs@lists.linux.dev,
Haobin Wu <853555@gmail.com>,
jack@suse.cz, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org,
aneesh.kumar@linux.vnet.ibm.com, willy@infradead.org,
dhowells@redhat.com, viro@zeniv.linux.org.uk, brauner@kernel.org
Subject: Re: [PATCH v3 3/3] 9p: skip over-long directory entry names for legacy 9p2000 too
Date: Tue, 22 Sep 2026 17:34:40 +0900 [thread overview]
Message-ID: <arI9oOXMsB-iG7jm@codewreck.org> (raw)
In-Reply-To: <2050867.PYKUYFuaPT@weasel>
Haobin Wu,
Thanks, I picked up all three patches
Christian Schoenebeck wrote on Fri, Sep 18, 2026 at 02:08:00PM +0200:
> On Friday, 18 September 2026 04:48:51 CEST Haobin Wu wrote:
> > The legacy 9p2000 and 9p2000.u readdir path, v9fs_dir_readdir(), parses
> > each entry with p9stat_read() and, unlike the 9p2000.L path, never had
> > a 256-byte name limit: a name of any length up to the wire maximum was
> > handed to dir_emit(). getdents64() therefore returned names longer than
> > NAME_MAX that no later syscall can use, and failed with -EIO for names
> > of PATH_MAX bytes or more.
> >
> > Apply the same NAME_MAX check as the previous patch does for
> > v9fs_dir_readdir_dotl(), so both protocol variants behave the same.
> >
> > Note that this is a behaviour change for 9p2000 and 9p2000.u: entries
> > with names longer than NAME_MAX used to be listed and are now skipped.
>
> That sentence is a bit misleading, isn't it?
>
> Name length 256..4095:
> - before: listed, but unusable (ENAMETOOLONG)
> - now: entry skipped, fetch continues
>
> Name length >=4096:
> - before: aborts the entire fetch (similar to 9p2000.L side)
> - now: entry skipped, fetch continues
Right, I've shamelessly copied that in when applying
https://github.com/martinetd/linux/commit/55d6732b8015705a657d96fc5bd37fbed349624a
> > @@ -126,8 +128,16 @@ static int v9fs_dir_readdir(struct file *file, struct
> > dir_context *ctx) return -EIO;
> > }
> >
> > - over = !dir_emit(ctx, st.name, strlen(st.name),
> > - QID2INO(&st.qid), dt_type(&st));
> > + namelen = strlen(st.name);
> > + if (namelen > NAME_MAX) {
>
> ... maybe better if (namelen >= PATH_MAX) here for legacy 9p2000(.u)?
Given things won't work after the name is picked up anyway (from what I
tried at least stat didn't work), I don't think it matters much, but I'm
fine breaking compatibility here.
We can bring the limit back up to PATH_MAX if someone claims it's useful
somewhere.
> > + p9_debug(P9_DEBUG_ERROR,
> > + "skip dentry: name length %zu > NAME_MAX\n",
> > + namelen);
> > + over = false;
>
> Nit: alternative would be init over = false and dropping explicit assignment
> inside loop branch here. But that's already personal taste level.
(I actually had the same comment, so made the swap locally)
--
Dominique Martinet | Asmadeus
prev parent reply other threads:[~2026-09-22 8:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 2:48 [PATCH v3 0/3] 9p: handle long directory entry names in readdir Haobin Wu
2026-09-18 2:48 ` [PATCH v3 1/3] 9p: skip intermediate directory entry name copy in p9dirent_read() Haobin Wu
2026-09-18 11:07 ` Christian Schoenebeck
2026-09-18 2:48 ` [PATCH v3 2/3] 9p: skip directory entries with names longer than NAME_MAX Haobin Wu
2026-09-18 11:09 ` Christian Schoenebeck
2026-09-18 2:48 ` [PATCH v3 3/3] 9p: skip over-long directory entry names for legacy 9p2000 too Haobin Wu
2026-09-18 12:08 ` Christian Schoenebeck
2026-09-22 8:34 ` Dominique Martinet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arI9oOXMsB-iG7jm@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=853555@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=brauner@kernel.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=ericvh@kernel.org \
--cc=horms@kernel.org \
--cc=jack@suse.cz \
--cc=kuba@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=v9fs@lists.linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.