Re: [PATCH slab/for-next v4 3/8] mm/slab: use call_rcu() in unknown context if irqs are enabled

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Acquiring local_trylock in __kfree_rcu_sheaf() causes an invalid wait context lockdep warning when kvfree_call_rcu() is called under a raw spinlock.
--

--- Patch [3]: [PATCH slab/for-next v4 3/8] mm/slab: use call_rcu() in unknown context if irqs are enabled ---
commit 48ff7cace4bd8ff5a54e0dc53dea46c9c152b1ad
Author: Harry Yoo (Oracle) <harry@kernel.org>

mm/slab: use call_rcu() in unknown context if irqs are enabled

This patch optimizes the deferred call_rcu() path in __kfree_rcu_sheaf() by
checking if IRQs are disabled. If IRQs are enabled, it avoids falling back
to the deferred path since call_rcu() cannot be interrupted by itself in
this context.

Link: https://lore.kernel.org/linux-mm/CAADnVQKRVD5ZSnEKbZZU7w86gHbGHUug2pvzpgZTngNS+fg4rw@mail.gmail.com

> diff --git a/mm/slub.c b/mm/slub.c
> index 0c350274fbff4..680fe64aff72e 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -6136,8 +6136,12 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj, unsigned int free_flags)
>  	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 */
> +		/*
> +		 * With !allow_spin, we might have interrupted call_rcu()'s
> +		 * IRQ-disabled critical section. If IRQs are not disabled,
> +		 * we know that's not the case.
> +		 */
> +		if (unlikely(!allow_spin && irqs_disabled())) {
>  			rcu_sheaf->size--;
>  			local_unlock(&s->cpu_sheaves->lock);

[Severity: High]
This is a pre-existing issue, but does using local_unlock() here (and
local_trylock() earlier in __kfree_rcu_sheaf()) violate wait context rules?

The kvfree_call_rcu() path can be called with a raw spinlock held, such as
pi_lock.

Because local_trylock is treated as a sleeping lock under PREEMPT_RT
wait-type checking, acquiring it while holding a raw spinlock triggers a
lockdep "Invalid wait context" warning.

This happens because CONFIG_PROVE_RAW_LOCK_NESTING statically checks
declared wait-types rather than runtime behavior.

Is there a way to defer this freeing without taking local_trylock?

>  			goto fail;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-kfree_rcu_nolock-v4-0-964e03c41a4e@kernel.org?part=3