From: Haobin Wu <853555@gmail.com>
To: ericvh@kernel.org, lucho@ionkov.net, asmadeus@codewreck.org,
v9fs@lists.linux.dev
Cc: linux_oss@crudebyte.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: [PATCH v3 0/3] 9p: handle long directory entry names in readdir
Date: Fri, 18 Sep 2026 10:48:48 +0800 [thread overview]
Message-ID: <20260918024851.51229-1-853555@gmail.com> (raw)
A host directory entry whose name is longer than 255 bytes currently
makes 9p's readdir fail with -EIO and hides every entry after it, which
is how this was noticed on WSL (Plan 9 shares of Windows drives).
Patch 1 drops the copy into the fixed 256-byte p9_dirent::d_name and
uses the string p9pdu_vreadf() already allocated, so the listing no
longer aborts.
Patch 2 then skips entries whose name is longer than NAME_MAX in the
9p2000.L readdir instead of returning them to userspace, as discussed
with Dominique and Jan on v1: the VFS only enforces PATH_MAX in
verify_dirent_name(), and nothing can operate on such a name afterwards
anyway.
Patch 3 applies the same limit to the legacy 9p2000/9p2000.u readdir.
It is a separate commit because it changes behaviour there: such names
used to be listed.
On patch 3, to be explicit about why this is a behaviour change: the
256-byte limit lives in p9dirent_read(), whose only caller is the
9p2000.L path. v9fs_dir_readdir() parses with p9stat_read(), where
p9_wstat::name comes from the 's' conversion (kmalloc(len + 1), no
NAME_MAX check), so legacy really did emit over-long names.
Changes since v2:
- Patch 2: say why the entry is skipped in the debug message and log it
at P9_DEBUG_ERROR, the level of the strscpy() message it replaces
(Christian, Dominique).
- New patch 3: same NAME_MAX limit in v9fs_dir_readdir() for legacy
9p2000(.u), as its own commit (Christian, Dominique).
- Dropped the Assisted-by: trailers.
Changes since v1:
- Use my real name in From/Signed-off-by (Dominique).
- Split into two patches (Dominique).
- Reworded the subject and commit message of patch 1 to describe the
existing readdir path and clarify that no allocation is added
(Dominique).
- New patch 2 skipping entries longer than NAME_MAX (Dominique, Jan).
- Dropped the bouncing sripathik@in.ibm.com address from Cc.
v2: https://lore.kernel.org/all/20260916135403.15789-1-853555@gmail.com/
v1: https://lore.kernel.org/all/20260826064819.52523-1-853555@gmail.com/
Haobin Wu (3):
9p: skip intermediate directory entry name copy in p9dirent_read()
9p: skip directory entries with names longer than NAME_MAX
9p: skip over-long directory entry names for legacy 9p2000 too
fs/9p/vfs_dir.c | 31 +++++++++++++++++++++++++------
include/net/9p/client.h | 2 +-
net/9p/protocol.c | 12 ++----------
3 files changed, 28 insertions(+), 17 deletions(-)
base-commit: 028ef9c96e96197026887c0f092424679298aae8
--
2.54.0 (Apple Git-157)
next reply other threads:[~2026-09-18 2:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 2:48 Haobin Wu [this message]
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
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=20260918024851.51229-1-853555@gmail.com \
--to=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=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.