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@xxxxxxxxxxxxxxxxxx> >> 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
