[PATCH] sunrpc: instantiate rpc_pipefs dentry before publishing it

[PATCH] sunrpc: instantiate rpc_pipefs dentry before publishing it

[Avi Weiss]

rpc_mkpipe_dentry() publishes pipe->dentry before
d_make_persistent() attaches its inode. A concurrent
rpc_queue_upcall() or rpc_timeout_upcall_queue() can
conceivably dereference the dentry while d_inode() is NULL.

Attach the inode before publishing the dentry, restoring the
ordering used before the rpc_pipefs conversion refactor.

Fixes: 946e2256775e ("convert rpc_pipefs")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
---

Build-tested with x86 defconfig, CONFIG_SUNRPC=y, and W=1
using the net/sunrpc/rpc_pipe.o target.
Runtime concurrency reproducer: not run.

 net/sunrpc/rpc_pipe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index 9d349cfbc4831..6d005231bc334 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -665,8 +665,8 @@ int rpc_mkpipe_dentry(struct dentry *parent, const char *name,
 	rpci->private = private;
 	rpci->pipe = pipe;
 	rpc_inode_setowner(inode, private);
-	pipe->dentry = dentry; // borrowed
 	d_make_persistent(dentry, inode);
+	pipe->dentry = dentry; // borrowed
 	fsnotify_create(dir, dentry);
 	simple_done_creating(dentry);
 	return 0;

base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
-- 
2.43.0

Re: [PATCH] sunrpc: instantiate rpc_pipefs dentry before publishing it

[Al Viro]

On Mon, Oct 19, 2026 at 01:11:17PM +0300, Avi Weiss wrote:
> rpc_mkpipe_dentry() publishes pipe->dentry before
> d_make_persistent() attaches its inode. A concurrent
> rpc_queue_upcall() or rpc_timeout_upcall_queue() can
> conceivably dereference the dentry while d_inode() is NULL.

Details, please...  I have no objections against the reordering
per se, but I would like to understand the scenario leading to
such a concurrent call.

Re: [PATCH] sunrpc: instantiate rpc_pipefs dentry before publishing it

[Avi Weiss]

I was thinking of, for example, an existing NFSv4 client when
rpc_pipefs is mounted later. The mount creates the dentry for
it's idmap pipe, while an owner/group lookup could queue a
legacy idmap upcall on the same pipe.

The upcall doesn't take pipefs_sb_lock, and rpc_queue_upcall()
uses d_inode() once pipe->dentry is non-NULL, even with no readers.
That seems like it could leave a window before d_make_persistent()
completes.

I think there are other ways possible as well.

On Mon, 19 Oct 2026 at 17:05, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, Oct 19, 2026 at 01:11:17PM +0300, Avi Weiss wrote:
> > rpc_mkpipe_dentry() publishes pipe->dentry before
> > d_make_persistent() attaches its inode. A concurrent
> > rpc_queue_upcall() or rpc_timeout_upcall_queue() can
> > conceivably dereference the dentry while d_inode() is NULL.
>
> Details, please...  I have no objections against the reordering
> per se, but I would like to understand the scenario leading to
> such a concurrent call.