Re: 6.19 tmpfs __d_lookup() lockup

[Hugh Dickins <hughd@google.com>]

On Fri, 12 Dec 2025, Al Viro wrote:
> On Thu, Dec 11, 2025 at 09:57:15PM -0800, Hugh Dickins wrote:
> 
> > 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.)
> 
> 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!

Hugh