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

[Chandan Babu R <chandanbabu@kernel.org>]

On Tue, Jan 23, 2024 at 11:40:43 AM +0000, Al Viro wrote:
> 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?
>

The above bad commit was identified with
f7aff128d8c70493d614786ba7ec5f743feafe51 + 4931c524ee8bbdf890972b14d6fcd9e2c72602d9

4931c524ee8bbdf890972b14d6fcd9e2c72602d9 was obtained from work.dcache2 branch at
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git.

However the diff between those commits suggest that they should not impact the
bisect results,

# git diff --stat 4931c524ee8bbdf890972b14d6fcd9e2c72602d9..6367b491c17a34b28aece294bddfda1a36ec0377
 Documentation/filesystems/porting.rst | 8 ++++----
 fs/coda/cache.c                       | 3 ---
 2 files changed, 4 insertions(+), 7 deletions(-)

> 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.

I executed generic/388 for about 22 times without including
f7aff128d8c70493d614786ba7ec5f743feafe51 commit. The first few commits on
the git tree were,

9cae6cd3e74a (HEAD -> without-dcache-genocide) Merge remote-tracking branch 'alviro/work.dcache2' into without-dcache-genocide
53f99622a2b2 d_genocide(): move the extern into fs/internal.h
4931c524ee8b (alviro/work.dcache2) retain_dentry(): introduce a trimmed-down lockless variant
1b738f196eac __dentry_kill(): new locking scheme
e3640d37d056 d_prune_aliases(): use a shrink list

The indefinite loop bug could not be recreated with the above kernel.

-- 
Chandan