Re: [BUG REPORT] shrink_dcache_parent() loops indefinitely on a next-20240102 kernel

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

On Tue, Jan 23, 2024 at 11:31:00AM +0530, Chandan Babu R wrote:
> 
> The result of the above suggested bisect operation is,
> 
> # git bisect log
> # bad: [0695819b3988e7e4d8099f8388244c1549d230cc] __d_unalias() doesn't use inode argument
> # good: [b85ea95d086471afb4ad062012a4d73cd328fa86] Linux 6.7-rc1
> git bisect start 'HEAD' 'v6.7-rc1' 'fs/'
> # good: [b33c14c8618edfc00bf8963e3b0c8a2b19c9eaa4] Merge branch 'no-rebase-overlayfs' into work.dcache-misc
> git bisect good b33c14c8618edfc00bf8963e3b0c8a2b19c9eaa4
> # good: [ef8a633ee84d8b57eba1f5b2908a3e0bf61837aa] Merge branch 'merged-selinux' into work.dcache-misc
> git bisect good ef8a633ee84d8b57eba1f5b2908a3e0bf61837aa
> # good: [53f99622a2b24704766469af23360836432eb88a] d_genocide(): move the extern into fs/internal.h
> git bisect good 53f99622a2b24704766469af23360836432eb88a
> # bad: [ce54c803d57ab6e872b670f0b46fc65840c8d7ca] d_alloc_parallel(): in-lookup hash insertion doesn't need an RCU variant
> git bisect bad ce54c803d57ab6e872b670f0b46fc65840c8d7ca
> # bad: [f7aff128d8c70493d614786ba7ec5f743feafe51] get rid of DCACHE_GENOCIDE
> git bisect bad f7aff128d8c70493d614786ba7ec5f743feafe51
> # first bad commit: [f7aff128d8c70493d614786ba7ec5f743feafe51] get rid of DCACHE_GENOCIDE
> 
> 
> commit f7aff128d8c70493d614786ba7ec5f743feafe51
> Author: Al Viro <viro@zeniv.linux.org.uk>
> Date:   Sun Nov 12 21:38:48 2023 -0500
> 
>     get rid of DCACHE_GENOCIDE
> 
>     ... now that we never call d_genocide() other than from kill_litter_super()

Huh?  So you are seeing that on merge of f7aff128d8c70493d614786ba7ec5f743feafe51 +
6367b491c17a34b28aece294bddfda1a36ec0377, but not on
f7aff128d8c70493d614786ba7ec5f743feafe51^ + 6367b491c17a34b28aece294bddfda1a36ec0377?

Wait a minute...  That smells like a d_walk() seeing rename_lock touched when it's
ascending from a subtree (for the reasons that have nothing to do with any changes of
the tree we are walking) and deciding to take another pass through the damn thing.
Argh...

But that should've been a problem for that commit on its own, regardless of the
merge with work.dcache2...  OTOH, it probably ended up as quiet memory leak without
that merge...

OK, could you verify that revert of that commit is enough to recover?  Short-term
that would be the obvious solution, assuming this is all that happens there.
Longer term I'd probably prefer to avoid using d_walk() there, but that's
a separate story.