From: Harry Yoo <harry.yoo@oracle.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>, linux-mm@kvack.org
Subject: Re: Possible KCSAN/lockdep issue in -next barns
Date: Wed, 21 Jan 2026 16:17:24 +0900 [thread overview]
Message-ID: <aXB9hHM3T_Q6KzfA@hyeyoo> (raw)
In-Reply-To: <aXB68e_DtXsr7OcB@hyeyoo>
On Wed, Jan 21, 2026 at 04:06:25PM +0900, Harry Yoo wrote:
> On Tue, Jan 20, 2026 at 09:41:14PM -0800, Paul E. McKenney wrote:
> > Hello, Vlastimil,
> >
> > On the off-chance that this is useful new news. This happened in
> > rcutorture's TREE04 scenario running with KCSAN and lockdep enabled.
> >
> > Thoughts?
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > [ 253.872153] =============================
> > [ 253.872271] [ BUG: Invalid wait context ]
> > [ 253.872271] 6.19.0-rc6-next-20260120 #21508 Not tainted
> > [ 253.875774] -----------------------------
> > [ 253.877983] migration/1/23 is trying to lock:
> > [ 253.877983] ffff8afd01054e98 (&barn->lock){..-.}-{3:3}, at: barn_get_empty_sheaf+0x1d/0xb0
> > [ 253.877983] other info that might help us debug this:
> > [ 253.877983] context-{5:5}
> > [ 253.877983] 3 locks held by migration/1/23:
> > [ 253.877983] #0: ffff8afd01fd89a8 (&p->pi_lock){-.-.}-{2:2}, at: __balance_push_cpu_stop+0x3f/0x200
> > [ 253.877983] #1: ffffffff9f15c5c8 (rcu_read_lock){....}-{1:3}, at: cpuset_cpus_allowed_fallback+0x27/0x250
> > [ 253.877983] #2: ffff8afd1f470be0 ((local_lock_t *)&pcs->lock){+.+.}-{3:3}, at: __kfree_rcu_sheaf+0x52/0x3d0
> > [ 253.877983] stack backtrace:
> > [ 253.877983] CPU: 1 UID: 0 PID: 23 Comm: migration/1 Not tainted 6.19.0-rc6-next-20260120 #21508 PREEMPTLAZY
> > [ 253.877983] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> > [ 253.877983] Stopper: __balance_push_cpu_stop+0x0/0x200 <- balance_push+0x118/0x170
> > [ 253.877983] Call Trace:
> > [ 253.877983] <TASK>
> > [ 253.877983] __dump_stack+0x22/0x30
> > [ 253.877983] dump_stack_lvl+0x60/0x80
> > [ 253.877983] dump_stack+0x19/0x24
> > [ 253.877983] __lock_acquire+0xd3a/0x28e0
> > [ 253.877983] ? __lock_acquire+0x5a9/0x28e0
> > [ 253.877983] ? __lock_acquire+0x5a9/0x28e0
> > [ 253.877983] ? barn_get_empty_sheaf+0x1d/0xb0
> > [ 253.877983] lock_acquire+0xc3/0x270
> > [ 253.877983] ? barn_get_empty_sheaf+0x1d/0xb0
> > [ 253.877983] ? __kfree_rcu_sheaf+0x52/0x3d0
> > [ 253.877983] _raw_spin_lock_irqsave+0x47/0x70
> > [ 253.877983] ? barn_get_empty_sheaf+0x1d/0xb0
> > [ 253.877983] barn_get_empty_sheaf+0x1d/0xb0
> > [ 253.877983] ? __kfree_rcu_sheaf+0x52/0x3d0
> > [ 253.877983] __kfree_rcu_sheaf+0x19f/0x3d0
> > [ 253.877983] kvfree_call_rcu+0xaf/0x390
> > [ 253.877983] set_cpus_allowed_force+0xc8/0xf0
>
> set_cpus_allowed_force() is calling kfree_rcu() with a raw spinlock
> (pi_lock) held, but barn->lock is normal spinlock, lockdep prints an
> error because on PREEMPT_RT normal spinlocks are converted to
> sleeping locks but raw spinlocks are not.
>
> Hmm... but it isn't great to convert barn->lock to
> a raw spinlock just because of this?
No, on PREEMPT_RT kfree_call_rcu() doesn't use sheaves.
Is it benign and it's simply due to PROVE_RAW_LOCK_NESTING?
> > [ 253.877983] ? cpuset_cpus_allowed_fallback+0x27/0x250
> > [ 253.877983] cpuset_cpus_allowed_fallback+0x15d/0x250
> > [ 253.877983] select_fallback_rq+0x1d8/0x250
> > [ 253.877983] ? __pfx___balance_push_cpu_stop+0x10/0x10
> > [ 253.877983] __balance_push_cpu_stop+0x4f/0x200
> > [ 253.877983] cpu_stopper_thread+0x147/0x210
> > [ 253.877983] ? __pfx_cpu_stopper_thread+0x10/0x10
> > [ 253.877983] smpboot_thread_fn+0x24c/0x390
> > [ 253.877983] ? __pfx_smpboot_thread_fn+0x10/0x10
> > [ 253.877983] kthread+0x1fa/0x230
> > [ 253.877983] ? __pfx_smpboot_thread_fn+0x10/0x10
> > [ 253.877983] ? __pfx_kthread+0x10/0x10
> > [ 253.877983] ret_from_fork+0x157/0x2c0
> > [ 253.877983] ? __pfx_kthread+0x10/0x10
> > [ 253.877983] ret_from_fork_asm+0x1a/0x30
> > [ 253.877983] </TASK>
next prev parent reply other threads:[~2026-01-21 7:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 5:41 Paul E. McKenney
2026-01-21 7:06 ` Harry Yoo
2026-01-21 7:16 ` Vlastimil Babka
2026-01-21 7:17 ` Harry Yoo [this message]
2026-01-21 15:58 ` Paul E. McKenney
2026-01-22 1:24 ` Harry Yoo
2026-01-22 1:35 ` Paul E. McKenney
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=aXB9hHM3T_Q6KzfA@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=linux-mm@kvack.org \
--cc=paulmck@kernel.org \
--cc=vbabka@suse.cz \
/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