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@xxxxxxxxxxxxxxxxxx> 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.