Re: [PATCH for-next v3 4/9] mm/slab: use call_rcu() in unknown context if irqs are enabled

Harry Yoo <[email protected]>
Newsgroups org.kernel.vger.rcu,dev.linux.lists.linux-rt-devel,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <[email protected]>

On 6/24/26 11:30 PM, Pedro Falcato wrote:
> On Mon, Jun 15, 2026 at 08:05:58PM +0900, Harry Yoo (Oracle) wrote:
>> call_rcu() disables IRQs with local_irq_save() to protect its per-cpu
>> data structures. Therefore, if IRQs are not disabled, they cannot be
>> corrupted by reentrance into call_rcu(). So fall back to the deferred
>> path only when !allow_spin && irqs_disabled().
>>
>> The RCU subsystem does not guarantee this contractually, and this
>> optimization relies on RCU's implementation details. Ideally, it should
>> be removed once call_rcu_nolock() is supported by the RCU subsystem.
>>
>> Link: https://lore.kernel.org/linux-mm/CAADnVQKRVD5ZSnEKbZZU7w86gHbGHUug2pvzpgZTngNS+fg4rw@mail.gmail.com
>> Suggested-by: Alexei Starovoitov <[email protected]>
>> Signed-off-by: Harry Yoo (Oracle) <[email protected]>
>> ---
>>  mm/slub.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index b0d38d515386..6a3552b70683 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -6158,8 +6158,8 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj, bool allow_spin)
>>  	if (likely(rcu_sheaf->size < s->sheaf_capacity)) {
>>  		rcu_sheaf = NULL;
>>  	} else {
>> -		if (unlikely(!allow_spin)) {
>> -			/* call_rcu() cannot be called in an unknown context */
>> +		/* call_rcu() disables IRQs to protect percpu data structures */
>> +		if (unlikely(!allow_spin && irqs_disabled())) {
> 
> Perhaps this could be more neatly exposed by RCU? something like
> maybe_in_call_rcu().

Make sense if we need to keep this optimization for a long time, but
hopefully RCU would support call_rcu_nolock() soon (apparently Paul has
a plan [1]), rather than introducing maybe_in_call_rcu() just to drop
it soon.

But I don't have a strong opinion on this and
I'd leave that to RCU folks.

> Also, it's a bit odd that you're introducing code and
> then subsequently patching over it with an improvement. Maybe this could be
> squashed into patch 3?

I was hoping having it as a separate patch to make it easier for RCU
folks to take a look and provide ack or nack :)

[1]
https://lore.kernel.org/linux-mm/03da8742-3790-4428-84b8-11911bf44c9e@paulmck-laptop/

-- 
Cheers,
Harry / Hyeonggon
OpenPGP_signature.asc (application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCakIqdwAKCRCGXBN6rc5S
1hymAQDnrjBNhyfghMOQ1Y5XsS5xCPbM5nzOMMvxwieKQiGerQD/TIjtJEpF5Zy6
02PvBcB4Ksu+B1/s6N8O0omOEQOq6Q0=
=1j6o
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.