* Possible KCSAN/lockdep issue in -next barns
@ 2026-01-21 5:41 Paul E. McKenney
2026-01-21 7:06 ` Harry Yoo
0 siblings, 1 reply; 7+ messages in thread
From: Paul E. McKenney @ 2026-01-21 5:41 UTC (permalink / raw)
To: Vlastimil Babka; +Cc: linux-mm
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
[ 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>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Possible KCSAN/lockdep issue in -next barns 2026-01-21 5:41 Possible KCSAN/lockdep issue in -next barns Paul E. McKenney @ 2026-01-21 7:06 ` Harry Yoo 2026-01-21 7:16 ` Vlastimil Babka 2026-01-21 7:17 ` Harry Yoo 0 siblings, 2 replies; 7+ messages in thread From: Harry Yoo @ 2026-01-21 7:06 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Vlastimil Babka, linux-mm 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? > [ 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> -- Cheers, Harry / Hyeonggon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible KCSAN/lockdep issue in -next barns 2026-01-21 7:06 ` Harry Yoo @ 2026-01-21 7:16 ` Vlastimil Babka 2026-01-21 7:17 ` Harry Yoo 1 sibling, 0 replies; 7+ messages in thread From: Vlastimil Babka @ 2026-01-21 7:16 UTC (permalink / raw) To: Harry Yoo, Paul E. McKenney; +Cc: linux-mm 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> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible KCSAN/lockdep issue in -next barns 2026-01-21 7:06 ` Harry Yoo 2026-01-21 7:16 ` Vlastimil Babka @ 2026-01-21 7:17 ` Harry Yoo 2026-01-21 15:58 ` Paul E. McKenney 1 sibling, 1 reply; 7+ messages in thread From: Harry Yoo @ 2026-01-21 7:17 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Vlastimil Babka, linux-mm 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> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible KCSAN/lockdep issue in -next barns 2026-01-21 7:17 ` Harry Yoo @ 2026-01-21 15:58 ` Paul E. McKenney 2026-01-22 1:24 ` Harry Yoo 0 siblings, 1 reply; 7+ messages in thread From: Paul E. McKenney @ 2026-01-21 15:58 UTC (permalink / raw) To: Harry Yoo; +Cc: Vlastimil Babka, linux-mm On Wed, Jan 21, 2026 at 04:17:24PM +0900, Harry Yoo wrote: > 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? Unless your kernel is built with CONFIG_PREEMPT_RT=y, in which case it is a real bug that could call schedule() with preemption disabled. Thanx, Paul > > > [ 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> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible KCSAN/lockdep issue in -next barns 2026-01-21 15:58 ` Paul E. McKenney @ 2026-01-22 1:24 ` Harry Yoo 2026-01-22 1:35 ` Paul E. McKenney 0 siblings, 1 reply; 7+ messages in thread From: Harry Yoo @ 2026-01-22 1:24 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Vlastimil Babka, linux-mm On Wed, Jan 21, 2026 at 07:58:29AM -0800, Paul E. McKenney wrote: > On Wed, Jan 21, 2026 at 04:17:24PM +0900, Harry Yoo wrote: > > 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? > > Unless your kernel is built with CONFIG_PREEMPT_RT=y, in which case it > is a real bug that could call schedule() with preemption disabled. Right, but it's fine because this path is never called with CONFIG_PREEMPT_RT=y. Yesterday sent a fix to suppress this warning. Thanks for reporting it, Paul! -- Cheers, Harry / Hyeonggon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible KCSAN/lockdep issue in -next barns 2026-01-22 1:24 ` Harry Yoo @ 2026-01-22 1:35 ` Paul E. McKenney 0 siblings, 0 replies; 7+ messages in thread From: Paul E. McKenney @ 2026-01-22 1:35 UTC (permalink / raw) To: Harry Yoo; +Cc: Vlastimil Babka, linux-mm On Thu, Jan 22, 2026 at 10:24:32AM +0900, Harry Yoo wrote: > On Wed, Jan 21, 2026 at 07:58:29AM -0800, Paul E. McKenney wrote: > > On Wed, Jan 21, 2026 at 04:17:24PM +0900, Harry Yoo wrote: > > > 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? > > > > Unless your kernel is built with CONFIG_PREEMPT_RT=y, in which case it > > is a real bug that could call schedule() with preemption disabled. > > Right, but it's fine because this path is never called with > CONFIG_PREEMPT_RT=y. Yesterday sent a fix to suppress this warning. Ah, missed that, apologies! > Thanks for reporting it, Paul! Happy to help, whether with one "l" or two. ;-) Thanx, Paul ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-01-22 1:35 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-01-21 5:41 Possible KCSAN/lockdep issue in -next barns Paul E. McKenney 2026-01-21 7:06 ` Harry Yoo 2026-01-21 7:16 ` Vlastimil Babka 2026-01-21 7:17 ` Harry Yoo 2026-01-21 15:58 ` Paul E. McKenney 2026-01-22 1:24 ` Harry Yoo 2026-01-22 1:35 ` Paul E. McKenney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox