Re: [PATCH] fuse: prevent exchange/revalidate races

[Al Viro <viro@zeniv.linux.org.uk>]

On Wed, Sep 17, 2025 at 05:30:24PM +0200, Miklos Szeredi wrote:
> If a path component is revalidated while taking part in a
> rename(RENAME_EXCHANGE) request, userspace might find the already exchanged
> files, while the kernel still has the old ones in dcache.  This mismatch
> will cause the dentry to be invalidated (unhashed), resulting in
> "(deleted)" being appended to proc paths.
> 
> Prevent this by taking the inode lock shared for the dentry being
> revalidated.
> 
> Another race introduced by commit 5be1fa8abd7b ("Pass parent directory
> inode and expected name to ->d_revalidate()") is that the name passed to
> revalidate can be stale (rename succeeded after the dentry was looked up in
> the dcache).
> 
> By checking the name and the parent while the inode is locked, this issue
> can also be solved.
> 
> This doesn't deal with revalidate/d_splice_alias() races, which happens if
> a directory (which is cached) is moved on the server and the new location
> discovered by a lookup.  In this case the inode is not locked during the
> new lookup.

> +		inode_lock_shared(inode);
> +		if (entry->d_parent->d_inode != dir ||
> +		    !d_same_name(entry, entry, name)) {
> +			/* raced with rename, assume revalidated */

... and if the call of ->d_revalidate() had been with parent locked, you've
just got a deadlock in that case.