Re: 6.19 tmpfs __d_lookup() lockup

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

On Fri, Dec 12, 2025 at 05:02:25AM +0000, Al Viro wrote:
> On Thu, Dec 11, 2025 at 07:56:38PM -0800, Hugh Dickins wrote:
> 
> > Of course, 2313598222f9 ("convert ramfs and tmpfs") (of Feb 26 2024!)
> > comes out as the first failing commit, no surprise there.
> > 
> > I did try inserting a BUG_ON(node == node->next) on line 2438 of
> > fs/dcache.c, just after __d_lookup's hlist_bl_for_each_entry_rcu(),
> > and that BUG was immediately hit (but, for all I know, perhaps that's
> > an unreliable asserition, perhaps it's acceptable for a race to result
> > in a momentary node == node->next there).
> 
> Hmm...  Could you check if we are somehow hitting d_in_lookup(dentry)
> in d_make_persistent()?

Another question: is it a CONFIG_UNICODE build and are you running with
casefolding anywhere in the vicinity?  If so, does this thing reproduce
without that?

Because that's one potential area of difference between shmem and ramfs
(as well as just about anything else where tree-in-dcache might be
relevant); if that's where the breakage happens, it would narrow the
things down nicely...