Re: 6.19 tmpfs __d_lookup() lockup

[Hugh Dickins <hughd@google.com>]

On Fri, 12 Dec 2025, Al Viro wrote:
> 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...

No, sad to say, CONFIG_UNICODE is not set.

(I see why you're asking, I did notice from the diff that the
case-folding stuff in shmem.c used to do something different but
now the same in several places; but the case-folding people will
have to look out for themselves, it's beyond me.)

(And yes, I was being stupid in my previous response: once I looked
at how simple d_in_lookup() is, I understood your "hitting"; but at
least I gave the right answer, no, that warning does not show up.)

Hugh