From: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Kunwu Chan <kunwu.chan@hotmail.com>,
"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
hch <hch@lst.de>
Subject: Re: rcu stalls during fstests runs for xfs
Date: Thu, 29 Jan 2026 05:27:04 +0000 [thread overview]
Message-ID: <aXrl46PxeHQSpYbX@shinmob> (raw)
In-Reply-To: <fc611e8e-0da9-4b88-83ef-092d300307e3@paulmck-laptop>
On Jan 28, 2026 / 08:42, Paul E. McKenney wrote:
> On Wed, Jan 28, 2026 at 05:55:01PM +0800, Kunwu Chan wrote:
> > On 1/26/26 19:30, Shinichiro Kawasaki wrote:
> > > kernel: xfs/for-next, 51aba4ca399, v6.19-rc5+
> > > block device: dm-linear on HDD (non-zoned)
> > > xfs: zoned
> >
> > I had a quick look at the attached logs. Across the different runs, the
> > stall traces consistently show CPUs spending extended time in
> > |mm_get_cid()|along the mm/sched context switch path.
> >
> > This doesn’t seem to indicate an immediate RCU issue by itself, but it
> > raises the question of whether context switch completion can be delayed
> > for unusually long periods under these test configurations.
>
> Thank you all!
>
> Us RCU guys looked at this and it also looks to us that at least one
> part of this issue is that mm_get_cid() is spinning. This is being
> investigated over here:
>
> https://lore.kernel.org/all/877bt29cgv.ffs@tglx/
> https://lore.kernel.org/all/bdfea828-4585-40e8-8835-247c6a8a76b0@linux.ibm.com/
> https://lore.kernel.org/all/87y0lh96xo.ffs@tglx/
Knuwu, Paul and RCU experts, thank you very much. It's good to know that the
similar issue is already under investigation. I hope that a fix gets available
in timely manner.
> I have seen the static-key pattern called out by Dave Chinner when running
> KASAN on large systems. We worked around this by disabling KASAN's use
> of static keys. In case you were running KASAN in these tests.
As to KASAN, yes, I enable it in my test runs. I find three static-keys under
mm/kasan/*. I will think if they can be disabled in my test runs. Thanks.
next prev parent reply other threads:[~2026-01-29 5:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 11:30 rcu stalls during fstests runs for xfs Shinichiro Kawasaki
2026-01-26 23:05 ` Dave Chinner
2026-01-27 1:38 ` Shinichiro Kawasaki
2026-01-28 9:55 ` Kunwu Chan
2026-01-28 16:42 ` Paul E. McKenney
2026-01-29 5:27 ` Shinichiro Kawasaki [this message]
2026-01-29 17:46 ` Paul E. McKenney
2026-01-29 23:19 ` Paul E. McKenney
2026-01-30 11:16 ` Shinichiro Kawasaki
2026-02-06 9:33 ` Matthieu Baerts
2026-02-06 10:02 ` Shinichiro Kawasaki
2026-02-06 11:04 ` Matthieu Baerts
2026-02-13 1:26 ` Shinichiro Kawasaki
2026-02-20 19:01 ` Joel Fernandes
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=aXrl46PxeHQSpYbX@shinmob \
--to=shinichiro.kawasaki@wdc.com \
--cc=hch@lst.de \
--cc=kunwu.chan@hotmail.com \
--cc=linux-xfs@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.