[PATCH] vfs: Don't leak disconnected dentries on umount

[PATCH] vfs: Don't leak disconnected dentries on umount

[Jan Kara]

When user calls open_by_handle_at() on some inode that is not cached, we
will create disconnected dentry for it. If such dentry is a directory,
exportfs_decode_fh_raw() will then try to connect this dentry to the
dentry tree through reconnect_path(). It may happen for various reasons
(such as corrupted fs or race with rename) that the call to
lookup_one_unlocked() in reconnect_one() will fail to find the dentry we
are trying to reconnect and instead create a new dentry under the
parent. Now this dentry will not be marked as disconnected although the
parent still may well be disconnected (at least in case this
inconsistency happened because the fs is corrupted and .. doesn't point
to the real parent directory). This creates inconsistency in
disconnected flags but AFAICS it was mostly harmless. At least until
commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")
which removed adding of most disconnected dentries to sb->s_anon list.
Thus after this commit cleanup of disconnected dentries implicitely
relies on the fact that dput() will immediately reclaim such dentries.
However when some leaf dentry isn't marked as disconnected, as in the
scenario described above, the reclaim doesn't happen and the dentries
are "leaked". Memory reclaim can eventually reclaim them but otherwise
they stay in memory and if umount comes first, we hit infamous "Busy
inodes after unmount" bug. Make sure all dentries created under a
disconnected parent are marked as disconnected as well.

Reported-by: syzbot+1d79ebe5383fc016cf07@syzkaller.appspotmail.com
Fixes: f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
---
 fs/dcache.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/dcache.c b/fs/dcache.c
index 65cc11939654..3ec21f9cedba 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2557,6 +2557,8 @@ struct dentry *d_alloc_parallel(struct dentry *parent,
 	spin_lock(&parent->d_lock);
 	new->d_parent = dget_dlock(parent);
 	hlist_add_head(&new->d_sib, &parent->d_children);
+	if (parent->d_flags & DCACHE_DISCONNECTED)
+		new->d_flags |= DCACHE_DISCONNECTED;
 	spin_unlock(&parent->d_lock);
 
 retry:
-- 
2.51.0

Re: [PATCH] vfs: Don't leak disconnected dentries on umount

[Al Viro]

On Thu, Oct 02, 2025 at 05:55:07PM +0200, Jan Kara wrote:

> diff --git a/fs/dcache.c b/fs/dcache.c
> index 65cc11939654..3ec21f9cedba 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -2557,6 +2557,8 @@ struct dentry *d_alloc_parallel(struct dentry *parent,
>  	spin_lock(&parent->d_lock);
>  	new->d_parent = dget_dlock(parent);
>  	hlist_add_head(&new->d_sib, &parent->d_children);
> +	if (parent->d_flags & DCACHE_DISCONNECTED)
> +		new->d_flags |= DCACHE_DISCONNECTED;
>  	spin_unlock(&parent->d_lock);

Not a good place for that |=, IMO...

Re: [PATCH] vfs: Don't leak disconnected dentries on umount

[Jan Kara]

On Thu 02-10-25 17:36:49, Al Viro wrote:
> On Thu, Oct 02, 2025 at 05:55:07PM +0200, Jan Kara wrote:
> 
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 65cc11939654..3ec21f9cedba 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -2557,6 +2557,8 @@ struct dentry *d_alloc_parallel(struct dentry *parent,
> >  	spin_lock(&parent->d_lock);
> >  	new->d_parent = dget_dlock(parent);
> >  	hlist_add_head(&new->d_sib, &parent->d_children);
> > +	if (parent->d_flags & DCACHE_DISCONNECTED)
> > +		new->d_flags |= DCACHE_DISCONNECTED;
> >  	spin_unlock(&parent->d_lock);
> 
> Not a good place for that |=, IMO...

The second place I was considering was a bit earlier where we set
DCACHE_PAR_LOOKUP in new->d_flags but then I've decided to put this under
parent's d_lock so that parent->d_flags cannot change under us. But in
principle that race is harmless so do you prefer to move this setting out
of parent->d_lock critical section?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] vfs: Don't leak disconnected dentries on umount

[Christian Brauner]

On Thu, 02 Oct 2025 17:55:07 +0200, Jan Kara wrote:
> When user calls open_by_handle_at() on some inode that is not cached, we
> will create disconnected dentry for it. If such dentry is a directory,
> exportfs_decode_fh_raw() will then try to connect this dentry to the
> dentry tree through reconnect_path(). It may happen for various reasons
> (such as corrupted fs or race with rename) that the call to
> lookup_one_unlocked() in reconnect_one() will fail to find the dentry we
> are trying to reconnect and instead create a new dentry under the
> parent. Now this dentry will not be marked as disconnected although the
> parent still may well be disconnected (at least in case this
> inconsistency happened because the fs is corrupted and .. doesn't point
> to the real parent directory). This creates inconsistency in
> disconnected flags but AFAICS it was mostly harmless. At least until
> commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")
> which removed adding of most disconnected dentries to sb->s_anon list.
> Thus after this commit cleanup of disconnected dentries implicitely
> relies on the fact that dput() will immediately reclaim such dentries.
> However when some leaf dentry isn't marked as disconnected, as in the
> scenario described above, the reclaim doesn't happen and the dentries
> are "leaked". Memory reclaim can eventually reclaim them but otherwise
> they stay in memory and if umount comes first, we hit infamous "Busy
> inodes after unmount" bug. Make sure all dentries created under a
> disconnected parent are marked as disconnected as well.
> 
> [...]

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.fixes

[1/1] vfs: Don't leak disconnected dentries on umount
      https://git.kernel.org/vfs/vfs/c/56094ad3eaa2