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

[sashiko-bot]

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

Pre-existing issues:
- [High] Acquiring a local_trylock inside a raw_spinlock_t wait context triggers a lockdep Invalid wait context warning.
--

commit 05f00697f28bd84542538d9e89bbc00e3f7a427a
Author: Harry Yoo (Oracle) <harry@xxxxxxxxxx>

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

This commit modifies the fallback logic for deferred RCU freeing in the
slab allocator. It now uses call_rcu() even in an unknown context as long
as interrupts are enabled.

Link: https://lore.kernel.org/linux-mm/CAADnVQKRVD5ZSnEKbZZU7w86gHbGHUug2pvzpgZTngNS+fg4rw@xxxxxxxxxxxxxx

> diff --git a/mm/slub.c b/mm/slub.c
> index b0d38d5153865..6a3552b70683d 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 */

[Severity: High]
This isn't a bug introduced by this patch, but since you are modifying
__kfree_rcu_sheaf() here, can this function trigger an invalid wait context
warning in lockdep?

According to the RCU guidelines, kvfree_call_rcu() is frequently called
while holding a raw_spinlock_t (such as pi_lock in kernel/sched/core.c)
and from hardirq context:

mm/slab_common.c:kvfree_call_rcu() {
    ...
    if (kfree_rcu_sheaf(ptr))
        return;
    ...
}

This calls into __kfree_rcu_sheaf(), which unconditionally attempts to
acquire a local_lock earlier in the function:

mm/slub.c:__kfree_rcu_sheaf() {
    ...
    if (!local_trylock(&s->cpu_sheaves->lock))
        goto fail;
    ...
}

Because local_lock has a lower lockdep wait type than raw_spinlock_t,
does this wait context inversion violate nesting rules and trigger
warnings? 

Guarding lock_map_acquire_try with !IS_ENABLED(CONFIG_PREEMPT_RT) does not
prevent this because local_trylock internally checks wait contexts
regardless. Could this lead to panics on systems with panic_on_warn enabled?

> +		if (unlikely(!allow_spin && irqs_disabled())) {
>  			rcu_sheaf->size--;
>  			local_unlock(&s->cpu_sheaves->lock);
>  			goto fail;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-kfree_rcu_nolock-v3-0-70a54f3775bb@xxxxxxxxxx?part=4