Le Wed, Jul 09, 2025 at 04:11:15PM +0530, neeraj.upadh...@kernel.org a écrit : > From: "Paul E. McKenney" <paul...@kernel.org> > > On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is > invoked within an interrupts-disabled region of code [1], it will invoke > rcu_read_unlock_special(), which uses an irq-work handler to force the > system to notice when the RCU read-side critical section actually ends. > That end won't happen until interrupts are enabled at the soonest. > > In some kernels, such as those booted with rcutree.use_softirq=y, the > irq-work handler is used unconditionally. > > The per-CPU rcu_data structure's ->defer_qs_iw_pending field is > updated by the irq-work handler and is both read and updated by > rcu_read_unlock_special(). This resulted in the following KCSAN splat: > > ------------------------------------------------------------------------ > > BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / > rcu_read_unlock_special > > read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: > rcu_read_unlock_special+0x175/0x260 > __rcu_read_unlock+0x92/0xa0 > rt_spin_unlock+0x9b/0xc0 > __local_bh_enable+0x10d/0x170 > __local_bh_enable_ip+0xfb/0x150 > rcu_do_batch+0x595/0xc40 > rcu_cpu_kthread+0x4e9/0x830 > smpboot_thread_fn+0x24d/0x3b0 > kthread+0x3bd/0x410 > ret_from_fork+0x35/0x40 > ret_from_fork_asm+0x1a/0x30 > > write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: > rcu_preempt_deferred_qs_handler+0x1e/0x30 > irq_work_single+0xaf/0x160 > run_irq_workd+0x91/0xc0 > smpboot_thread_fn+0x24d/0x3b0 > kthread+0x3bd/0x410 > ret_from_fork+0x35/0x40 > ret_from_fork_asm+0x1a/0x30 > > no locks held by irq_work/8/88. > irq event stamp: 200272 > hardirqs last enabled at (200272): [<ffffffffb0f56121>] > finish_task_switch+0x131/0x320 > hardirqs last disabled at (200271): [<ffffffffb25c7859>] > __schedule+0x129/0xd70 > softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 > softirqs last disabled at (0): [<0000000000000000>] 0x0 > > ------------------------------------------------------------------------ > > The problem is that irq-work handlers run with interrupts enabled, which > means that rcu_preempt_deferred_qs_handler() could be interrupted, > and that interrupt handler might contain an RCU read-side critical > section, which might invoke rcu_read_unlock_special(). In the strict > KCSAN mode of operation used by RCU, this constitutes a data race on > the ->defer_qs_iw_pending field. > > This commit therefore disables interrupts across the portion of the > rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending > field. This suffices because this handler is not a fast path. > > Signed-off-by: Paul E. McKenney <paul...@kernel.org> > Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadh...@kernel.org>
Reviewed-by: Frederic Weisbecker <frede...@kernel.org> -- Frederic Weisbecker SUSE Labs
