Re: [PATCH slab/for-next v4 4/8] mm/slab: extend deferred free mechanism to handle rcu sheaves

[sashiko-bot]

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

Pre-existing issues:
- [High] `__kfree_rcu_sheaf()` acquires a lock using `local_trylock()`, which triggers a lockdep 'Invalid wait context' warning when called via `kvfree_call_rcu()`.
--

--- Patch [4]: [PATCH slab/for-next v4 4/8] mm/slab: extend deferred free mechanism to handle rcu sheaves ---
commit 136141e9d7cd5370bbb83aa5e26b9b28ea8267ad
Author: Harry Yoo (Oracle) <harry@xxxxxxxxxx>

mm/slab: extend deferred free mechanism to handle rcu sheaves

This commit extends the deferred free mechanism to handle RCU sheaves when
spinning is not allowed and IRQs are disabled. It queues the RCU sheaf on
an IRQ work to safely invoke call_rcu() later, and updates barrier syncs.

> diff --git a/mm/slub.c b/mm/slub.c
> index 680fe64aff72e..8afa6b47b1f2b 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c

[ ... ]

> @@ -6154,8 +6161,22 @@ bool __kfree_rcu_sheaf(struct kmem_cache *s, void *obj, unsigned int free_flags)
>  	 * we flush before local_unlock to make sure a racing
>  	 * flush_all_rcu_sheaves() doesn't miss this sheaf
>  	 */
> -	if (rcu_sheaf)
> -		call_rcu(&rcu_sheaf->rcu_head, rcu_free_sheaf);
> +	if (rcu_sheaf) {
> +		/*
> +		 * 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())) {
> +			struct deferred_percpu_work *dpw;
> +
> +			dpw = this_cpu_ptr(&deferred_percpu_work);
> +			if (llist_add(&rcu_sheaf->llnode, &dpw->rcu_sheaves))
> +				irq_work_queue(&dpw->work);
> +		} else {
> +			call_rcu(&rcu_sheaf->rcu_head, rcu_free_sheaf);
> +		}
> +	}

[Severity: High]
This isn't a bug introduced by this patch, but since this modifies
__kfree_rcu_sheaf(), I wanted to ask about a preexisting locking issue in
this execution path.

Earlier in __kfree_rcu_sheaf(), the code unconditionally acquires a lock via
local_trylock(&s->cpu_sheaves->lock). However, this function is reachable from
kvfree_call_rcu(), which can be called under a raw_spinlock_t (like pi_lock)
and from hardirq context:

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

which routes to:

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

Will acquiring a local_trylock within this wait context trigger a lockdep
"Invalid wait context" warning, since it statically violates the raw
spinlock locking rules?

>  
>  	local_unlock(&s->cpu_sheaves->lock);
>

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