From: Hugh Dickins <hughd@google.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Hugh Dickins <hughd@google.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Christian Brauner <brauner@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: 6.19 tmpfs __d_lookup() lockup
Date: Fri, 12 Dec 2025 02:12:17 -0800 (PST) [thread overview]
Message-ID: <bed18e79-ab2b-2a8f-0c32-77e6d27e2a05@google.com> (raw)
In-Reply-To: <2a102c6d-82d9-2751-cd31-c836b5c739b7@google.com>
On Thu, 11 Dec 2025, Hugh Dickins wrote:
> On Fri, 12 Dec 2025, Al Viro wrote:
> >
> > A few more things to check:
> >
> > 1) do we, by any chance, ever see dentry_free() called with
> > dentry->d_flags & DCACHE_PERSISTENT?
>
> No.
>
> >
> > 2) does d_make_persistent() ever call __d_rehash() when called with
> > dentry->d_sb->s_magic == TMPFS_MAGIC?
>
> Yes, both if shmem_whiteout() does its d_rehash() and if it does not.
>
> >
> > 3) is shmem_whiteout() ever called? If that's the case, could you try
> > to remove that d_rehash() call in it and see what happens? Because
> > that's another place where shmem is playing odd games...
>
> Yes, shmem_whiteout() does get called.
>
> And when I remove that d_rehash() call from it, 269 476 650 and 750
> complete without locking up. And when I remove the WARN_ON()s
> inserted for 2) and 3), then they pass.
>
> You are very much on the right lines!
Well, more than that: it's exactly the right thing to do, isn't it?
shmem_mknod() already called d_make_peristent() which called __d_rehash(),
calling it a second time naturally leads to the __d_lookup() lockup seen.
And I can't see a place now for shmem_whiteout()'s "Cheat and hash" comment.
Al, may I please leave you to send in the fix to Christian and/or Linus?
You may have noticed other things on the way, that you might want to add.
But if your patch resembles the below (which has now passed xfstests
auto runs on tmpfs), please feel free to add or omit any or all of
Reported-by: Hugh Dickins <hughd@google.com>
Acked-by: Hugh Dickins <hughd@google.com>
Tested-by: Hugh Dickins <hughd@google.com>
Thanks a lot for your very quick resolution!
Hugh
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -4023,18 +4023,7 @@ static int shmem_whiteout(struct mnt_idmap *idmap,
error = shmem_mknod(idmap, old_dir, whiteout,
S_IFCHR | WHITEOUT_MODE, WHITEOUT_DEV);
dput(whiteout);
- if (error)
- return error;
-
- /*
- * Cheat and hash the whiteout while the old dentry is still in
- * place, instead of playing games with FS_RENAME_DOES_D_MOVE.
- *
- * d_lookup() will consistently find one of them at this point,
- * not sure which one, but that isn't even important.
- */
- d_rehash(whiteout);
- return 0;
+ return error;
}
/*
next prev parent reply other threads:[~2025-12-12 10:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 3:56 Hugh Dickins
2025-12-12 5:02 ` Al Viro
2025-12-12 5:15 ` Hugh Dickins
2025-12-12 5:34 ` Al Viro
2025-12-12 5:57 ` Hugh Dickins
2025-12-12 6:30 ` Al Viro
2025-12-12 7:17 ` Hugh Dickins
2025-12-12 10:12 ` Hugh Dickins [this message]
2025-12-13 7:22 ` Al Viro
2025-12-14 3:27 ` shmem_rename() bugs (was Re: 6.19 tmpfs __d_lookup() lockup) Al Viro
2025-12-14 3:30 ` [PATCH 1/2] shmem_whiteout(): fix regression from tree-in-dcache series Al Viro
2025-12-14 3:30 ` [RFC][PATCH 2/2] shmem: fix recovery on rename failures Al Viro
2025-12-15 7:38 ` Hugh Dickins
2025-12-15 11:58 ` Christian Brauner
2025-12-15 16:03 ` Chuck Lever
2025-12-15 16:54 ` Al Viro
2025-12-16 6:02 ` [git pull] shmem rename fixes Al Viro
2025-12-16 8:04 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bed18e79-ab2b-2a8f-0c32-77e6d27e2a05@google.com \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox