Thread (4 messages) 4 messages, 3 authors, 2025-09-13

Re: [PATCH] rcu: Remove redundant rcu_read_lock/unlock() in spin_lock critical sections

From: Waiman Long <hidden>
Date: 2025-09-13 00:33:37
Also in: cgroups, intel-gfx, linux-acpi, linux-fsdevel, linux-nfs, linux-rt-devel, linux-s390, linux-security-module, lkml

On 9/12/25 5:35 PM, Sebastian Andrzej Siewior wrote:
On 2025-09-12 17:13:09 [-0400], Waiman Long wrote:
quoted
On 9/12/25 2:50 AM, pengdonglin wrote:
quoted
From: pengdonglin <redacted>

When CONFIG_PREEMPT_RT is disabled, spin_lock*() operations implicitly
disable preemption, which provides RCU read-side protection. When
CONFIG_PREEMPT_RT is enabled, spin_lock*() implementations internally
manage RCU read-side critical sections.
I have some doubt about your claim that disabling preemption provides RCU
read-side protection. It is true for some flavors but probably not all. I do
know that disabling interrupt will provide RCU read-side protection. So for
spin_lock_irq*() calls, that is valid. I am not sure about spin_lock_bh(),
maybe it applies there too. we need some RCU people to confirm.
The claim is valid since Paul merged the three flavours we had. Before
that preempt_disable() (and disabling irqs) would match
rcu_read_lock_sched(). rcu_read_lock() and rcu_read_lock_bh() were
different in terms of grace period and clean up.
So _now_ we could remove it if it makes things easier.
Thanks for the clarification.

In this case, I think the patch description should mention the commit 
that unify the 3 RCU flavors to make sure that this patch won't be 
accidentally backport'ed to an older kernel without the necessary 
prerequisite commit(s).

Cheers,
Longman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help