From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: ericvh@kernel.org, lucho@ionkov.net, asmadeus@codewreck.org,
v9fs@lists.linux.dev, Haobin Wu <853555@gmail.com>
Cc: 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: Fri, 18 Sep 2026 14:08:00 +0200 [thread overview]
Message-ID: <2050867.PYKUYFuaPT@weasel> (raw)
In-Reply-To: <20260918024851.51229-4-853555@gmail.com>
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
But yes, it would be a user-space change nevertheless, so ...
> Suggested-by: Christian Schoenebeck <linux_oss@crudebyte.com>
> Link: https://lore.kernel.org/all/3910569.MHq7AAxBmi@weasel/
> Signed-off-by: Haobin Wu <853555@gmail.com>
> ---
> fs/9p/vfs_dir.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
> index 08d1a3429654..31de9ac913f0 100644
> --- a/fs/9p/vfs_dir.c
> +++ b/fs/9p/vfs_dir.c
> @@ -119,6 +119,8 @@ static int v9fs_dir_readdir(struct file *file, struct
> dir_context *ctx) rdir->tail = n;
> }
> while (rdir->head < rdir->tail) {
> + size_t namelen;
> +
> err = p9stat_read(fid->clnt, rdir->buf + rdir->head,
> rdir->tail - rdir->head, &st);
> if (err <= 0) {
> @@ -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)?
> + 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.
/Christian
> + } else {
> + over = !dir_emit(ctx, st.name, namelen,
> + QID2INO(&st.qid), dt_type(&st));
> + }
> p9stat_free(&st);
> if (over)
> return 0;
next prev parent reply other threads:[~2026-09-18 12:08 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 [this message]
2026-09-22 8:34 ` Dominique Martinet
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=2050867.PYKUYFuaPT@weasel \
--to=linux_oss@crudebyte.com \
--cc=853555@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=asmadeus@codewreck.org \
--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=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.