linux.git/fs/9p, branch master

Merge tag '9p-for-7.2-rc1' of https://github.com/martinetd/linux

2026-06-21T17:26:31+00:00

Pull 9p updates from Dominique Martinet:
 "Asides of the avalanche of LLM-driven fixes, there are a couple of big
  changes this cycle:

   - negative dentry and symlink cache

   - a way out of the unkillable "io_wait_event_killable" (because it
     looped around waiting for the request flush to come back from
     server; this has been bugging syzcaller folks since forever): I'm
     still not 100% sure about this patch, but I think it's as good as
     we'll ever get, and will keep testing a bit further in the coming
     weeks

  The rest is more noisy than usual, but shouldn't cause any trouble"

* tag '9p-for-7.2-rc1' of https://github.com/martinetd/linux:
  9p: Add missing read barrier in virtio zero-copy path
  net/9p: Replace strlen() strcpy() pair with strscpy()
  9p: skip nlink update in cacheless mode to fix WARN_ON
  net/9p: fix race condition on rdma->state in trans_rdma.c
  9p: v9fs_file_do_lock: replace WARN_ONCE with p9_debug
  9p: Enable symlink caching in page cache
  9p: Set default negative dentry retention time for cache=loose
  9p: Add mount option for negative dentry cache retention
  9p: Cache negative dentries for lookup performance
  9p: avoid returning ERR_PTR(0) from mkdir operations
  9p: avoid putting oldfid in p9_client_walk() error path
  net/9p: fix infinite loop in p9_client_rpc on fatal signal
  docs/filesystems/9p: fix broken external links
  9p: invalidate readdir buffer on seek
  9p: use kvzalloc for readdir buffer
  net/9p/usbg: Constify struct configfs_item_operations

9p: skip nlink update in cacheless mode to fix WARN_ON

2026-06-21T05:22:57+00:00

v9fs_dec_count() unconditionally calls drop_nlink() on regular files,
even when the inode's nlink is already zero. In cacheless mode the
client refetches inode metadata from the server (the source of truth)
on every operation, so by the time v9fs_remove() returns, the locally
cached nlink may already reflect the post-unlink value:

  1. Client initiates unlink, server processes it and sets nlink to 0
  2. Client refetches inode metadata (nlink=0) before unlink returns
  3. Client's v9fs_remove() completes successfully
  4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0

This race is easily triggered under heavy unlink workloads, such as
stress-ng's unlink stressor, producing the following warning:

  WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8
  Call trace:
   drop_nlink+0x4c/0xc8
   v9fs_remove+0x1e0/0x250 [9p]
   v9fs_vfs_unlink+0x20/0x38 [9p]
   vfs_unlink+0x13c/0x258
   ...

In cacheless mode the server is authoritative and the inode is on its
way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count()
entirely when neither CACHE_META nor CACHE_LOOSE is set, which both
avoids the warning and removes a class of nlink races (two concurrent
unlinkers observing nlink > 0 and both calling drop_nlink()) that an
nlink == 0 guard alone would only narrow rather than close.

Fixes: ac89b2ef9b55 ("9p: don't maintain dir i_nlink if the exported fs doesn't either")
Cc: stable@vger.kernel.org
Suggested-by: Dominique Martinet 
Signed-off-by: Breno Leitao 
Message-ID: <20260421-9p-v2-1-48762d294fad@debian.org>
Signed-off-by: Dominique Martinet

9p: v9fs_file_do_lock: replace WARN_ONCE with p9_debug

2026-06-21T05:22:57+00:00

This warning depends on server-provided data, we should not use
WARN here

Reported-by: Yifei Chu 
Closes: https://lore.kernel.org/r/CAPJnbgJ7ZK7DCjCfG56hd_iKGePmAzudb4hOWd4=9r32nM+KcA@mail.gmail.com
Signed-off-by: Dominique Martinet 
Message-ID: <20260529-lock-warn-v1-1-20c29580d61d@codewreck.org>

9p: Enable symlink caching in page cache

2026-06-21T05:22:57+00:00

Currently, when cache=loose is enabled, file reads are cached in the
page cache, but symlink reads are not. This patch allows the results
of p9_client_readlink() to be stored in the page cache, eliminating
the need for repeated 9P transactions on subsequent symlink accesses.

This change improves performance for workloads that involve frequent
symlink resolution.

Signed-off-by: Remi Pommarel 
Message-ID: <982462d17c0c0d2856763266a25eb04d080c1dbb.1779355927.git.repk@triplefau.lt>
Signed-off-by: Dominique Martinet

9p: Set default negative dentry retention time for cache=loose

2026-06-21T05:22:57+00:00

For cache=loose mounts, set the default negative dentry cache retention
time to 24 hours.

Signed-off-by: Remi Pommarel 
Message-ID: 
Signed-off-by: Dominique Martinet

9p: Add mount option for negative dentry cache retention

2026-06-21T05:22:56+00:00

Introduce a new mount option, negtimeout, for v9fs that allows users
to specify how long negative dentries are retained in the cache. The
retention time can be set in milliseconds (e.g. negtimeout=10000 for
a 10secs retention time) or a negative value (e.g. negtimeout=-1) to
keep negative entries until the buffer cache management removes them.

For consistency reasons, this option should only be used in exclusive
or read-only mount scenarios, aligning with the cache=loose usage.

Signed-off-by: Remi Pommarel 
Message-ID: 
Signed-off-by: Dominique Martinet

9p: Cache negative dentries for lookup performance

2026-06-21T05:22:56+00:00

Not caching negative dentries can result in poor performance for
workloads that repeatedly look up non-existent paths. Each such
lookup triggers a full 9P transaction with the server, adding
unnecessary overhead.

A typical example is source compilation, where multiple cc1 processes
are spawned and repeatedly search for the same missing header files
over and over again.

This change enables caching of negative dentries, so that lookups for
known non-existent paths do not require a full 9P transaction. The
cached negative dentries are retained for a configurable duration
(expressed in milliseconds), as specified by the ndentry_timeout
field in struct v9fs_session_info. If set to -1, negative dentries
are cached indefinitely.

This optimization reduces lookup overhead and improves performance for
workloads involving frequent access to non-existent paths.

Signed-off-by: Remi Pommarel 
Message-ID: 
Signed-off-by: Dominique Martinet

9p: avoid returning ERR_PTR(0) from mkdir operations

2026-06-21T05:22:56+00:00

When mkdir succeeds, v9fs_vfs_mkdir_dotl() and v9fs_vfs_mkdir() return
ERR_PTR(0) which is incorrect. They should return NULL instead for
success and ERR_PTR() only with negative error codes for failure.

Return NULL instead of passing to ERR_PTR while err is zero
Fixes smatch warnings:
  fs/9p/vfs_inode_dotl.c:420 v9fs_vfs_mkdir_dotl() warn: passing zero to 'ERR_PTR'
  fs/9p/vfs_inode.c:695 v9fs_vfs_mkdir() warn: passing zero to 'ERR_PTR'

The v9fs_vfs_mkdir() code was further simplified because v9fs_create()
can never return NULL, so we do not need to check for fid being set
separately, and the error path can be a simple return immediately after
v9fs_create() failure.
There is no intended functional change.

Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *")
Suggested-by: David Laight 
Acked-by: Christian Schoenebeck 
Signed-off-by: Hongling Zeng 
Message-ID: <20260520022650.14217-1-zenghongling@kylinos.cn>
Signed-off-by: Dominique Martinet

9p: invalidate readdir buffer on seek

2026-05-19T11:58:18+00:00

The per-fid readdir buffer (fid->rdir) is populated lazily and only
refilled when fully drained (rdir->head == rdir->tail). userspace
lseek() on a directory fd updates file->f_pos via generic_file_llseek()
but does not touch the cached buffer, so the next getdents() iterates
the stale cache and emits entries from the previous position instead
of the one the caller asked for.

Track the file position the cached data corresponds to in
struct p9_rdir, and drop the cache on entry to iterate_shared when it
no longer matches ctx->pos. The 9p protocol's Tread/Treaddir already
take an arbitrary offset on every request, so a refill at the new
position is always legal; no .llseek override or seek restriction is
needed.

Reported-by: Pierre Barre 
Link: https://lore.kernel.org/v9fs/496d10b9-40fe-4f81-8014-37497c37ff63@app.fastmail.com/
Signed-off-by: Pierre Barre 
Message-ID: <20260512132032.369281-2-pierre@barre.sh>
Signed-off-by: Dominique Martinet

9p: use kvzalloc for readdir buffer

2026-05-19T11:58:18+00:00

The readdir buffer is sized to msize, so kzalloc() can fail under
fragmentation with a page allocation failure in v9fs_alloc_rdir_buf()
/ v9fs_dir_readdir_dotl().

The buffer is only a response sink and is never pack_sg_list()'d,
so kvzalloc() is safe for all transports, unlike the fcall buffers
fixed in e21d451a82f3 ("9p: Use kvmalloc for message buffers on
supported transports").

Signed-off-by: Pierre Barre 
Message-ID: <20260512132032.369281-1-pierre@barre.sh>
Signed-off-by: Dominique Martinet