linux-kernel - Re: [PATCH rcu 2/5] rcu: Protect ->defer_qs_iw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aG5SNJpn60Sz9px3@localhost.localdomain>
Date: Wed, 9 Jul 2025 13:27:48 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: neeraj.upadhyay@...nel.org
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, paulmck@...nel.org,
	joelagnelf@...dia.com, boqun.feng@...il.com, urezki@...il.com,
	rostedt@...dmis.org, mathieu.desnoyers@...icios.com,
	jiangshanlai@...il.com, qiang.zhang1211@...il.com,
	neeraj.iitr10@...il.com, neeraj.upadhyay@....com
Subject: Re: [PATCH rcu 2/5] rcu: Protect ->defer_qs_iw_pending from data race

Le Wed, Jul 09, 2025 at 04:11:15PM +0530, neeraj.upadhyay@...nel.org a écrit :
> From: "Paul E. McKenney" <paulmck@...nel.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 <paulmck@...nel.org>
> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@...nel.org>

Reviewed-by: Frederic Weisbecker <frederic@...nel.org>

-- 
Frederic Weisbecker
SUSE Labs