Re: Possible KCSAN/lockdep issue in -next barns

[Vlastimil Babka <vbabka@suse.cz>]

On 1/21/26 08:06, 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.

Hm right, Ulad did raise this issue and thus I made kvfree_call_rcu() skip
the kfree_rcu_sheaf() attempt on CONFIG_PREEMPT_RT.

But I forgot that lockdep (or a related debugging option) checks this
context even with !PREEMPT_RT.
We could skip kfree_rcu_sheaf() when this debugging is enabled? Not ideal.
Is there a way to detect such a context on runtime and only skip
kfree_rcu_sheaf() when really necessary?

> Hmm... but it isn't great to convert barn->lock to
> a raw spinlock just because of this?
> 
>> [  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>
>