public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chandan Babu R <chandanbabu@kernel.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-xfs@vger.kernel.org, brauner@kernel.org, jack@suse.cz
Subject: Re: [BUG REPORT] shrink_dcache_parent() loops indefinitely on a next-20240102 kernel
Date: Tue, 23 Jan 2024 11:31:00 +0530	[thread overview]
Message-ID: <87ede8787u.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20240118063930.GP1674809@ZenIV>

On Thu, Jan 18, 2024 at 06:39:30 AM +0000, Al Viro wrote:
> On Thu, Jan 18, 2024 at 10:59:06AM +0530, Chandan Babu R wrote:
>> On Thu, Jan 04, 2024 at 06:40:43 PM +0530, Chandan Babu R wrote:
>> > On Wed, Jan 03, 2024 at 08:34:20 PM -0800, Darrick J. Wong wrote:
>> >> On Wed, Jan 03, 2024 at 12:12:12PM +0530, Chandan Babu R wrote:
>> >>> Hi,
>> >>> 
>> >>> Executing fstests' recoveryloop test group on XFS on a next-20240102 kernel
>> >>> sometimes causes the following hung task report to be printed on the console,
>> >>> 
>> 
>> Meanwhile, I have executed some more experiments.
>> 
>> The bug can be recreated on a next-20240102 kernel by executing either
>> generic/388 or generic/475 for a maximum of 10 iterations. I tried to do a git
>> bisect based on this observation i.e. I would mark a commit as 'good' if the
>> bug does not get recreated within 10 iterations. This led to the following git
>> bisect log,
>
>> # bad: [119dcc73a9c2df0da002054cdb2296cb32b7cb93] Merge branches 'work.dcache-misc' and 'work.dcache2' into work.dcache
>> git bisect bad 119dcc73a9c2df0da002054cdb2296cb32b7cb93
>> # good: [6367b491c17a34b28aece294bddfda1a36ec0377] retain_dentry(): introduce a trimmed-down lockless variant
>> git bisect good 57851607326a2beef21e67f83f4f53a90df8445a
>> # good: [ef69f0506d8f3a250ac5baa96746e17ae22c67b5] __d_unalias() doesn't use inode argument
>
> Lovely...  Could you try to do the following:
>
> bisect from 6.7-rc1 to work.dcache-misc; for each of those revisions
> 	git worktree add ../test HEAD
> 	cd ../test
> 	git merge work.dcache2
> 	build
> 	test the result
> 	cd -
> 	git worktree remove -f ../test
> 	git bisect {good,bad} accordingly

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()

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

 fs/dcache.c            | 5 +----
 include/linux/dcache.h | 1 -
 2 files changed, 1 insertion(+), 5 deletions(-)

-- 
Chandan

  reply	other threads:[~2024-01-23  8:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-03  6:42 [BUG REPORT] shrink_dcache_parent() loops indefinitely on a next-20240102 kernel Chandan Babu R
2024-01-04  4:34 ` Darrick J. Wong
2024-01-04 13:10   ` Chandan Babu R
2024-01-18  5:29     ` Chandan Babu R
2024-01-18  6:39       ` Al Viro
2024-01-23  6:01         ` Chandan Babu R [this message]
2024-01-23 11:40           ` Al Viro
2024-01-25  6:31             ` Chandan Babu R
2024-02-03 13:05               ` Dominique Martinet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ede8787u.fsf@debian-BULLSEYE-live-builder-AMD64 \
    --to=chandanbabu@kernel.org \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox