Re: [PATCH v5 2/8] mm/slab: handle the !allow_spin case in kfree_rcu_sheaf()

[sashiko-bot]

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

New issues:
- [High] Kmemleak symmetry violation when a sheaf allocated with SLAB_ALLOC_NOLOCK is freed with standard kfree().

Pre-existing issues:
- [High] Lock recursion deadlock via kswapd wakeup from raw spinlock context due to GFP_NOWAIT usage.
--

--- Patch [2]: [PATCH v5 2/8] mm/slab: handle the !allow_spin case in kfree_rcu_sheaf() ---
commit 10fcb5282968708fbb08270a6618140198eda999
Author: Harry Yoo (Oracle) <harry@xxxxxxxxxx>
mm/slab: handle the !allow_spin case in kfree_rcu_sheaf()

This patch teaches kfree_rcu_sheaf() how to handle the !allow_spin case by
introducing free_flags. It attempts to get an empty sheaf even when spinning
is not allowed, translating free_flags to alloc_flags during allocation. It
also ensures kfree_rcu_sheaf() fails when the RCU sheaf becomes full in an
unknown context.

Link: https://lore.kernel.org/linux-mm/872bd673-3d45-4111-8a41-31185db3ece5@xxxxxxxxxx

> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 1e1d3feec3535..42db62f3e801a 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1638,7 +1638,7 @@ static bool kfree_rcu_sheaf(void *obj)
>  
>  	s = slab->slab_cache;
>  	if (likely(!IS_ENABLED(CONFIG_NUMA) || slab_nid(slab) == numa_mem_id()))
> -		return __kfree_rcu_sheaf(s, obj);
> +		return __kfree_rcu_sheaf(s, obj, SLAB_FREE_DEFAULT);

[Severity: High]
This isn't a bug introduced by this patch, but does this unconditional use of
SLAB_FREE_DEFAULT here cause a lock recursion deadlock?

Because SLAB_FREE_DEFAULT evaluates allow_spin to true, __kfree_rcu_sheaf()
will use GFP_NOWAIT. GFP_NOWAIT includes __GFP_KSWAPD_RECLAIM, which can
trigger wakeup_kswapd().

Since kfree_rcu() (via kvfree_call_rcu()) can be called while holding
scheduler internal raw spinlocks like pi_lock, waking kswapd enters
try_to_wake_up() which attempts to acquire pi_lock again, deadlocking the
system.

>  
>  	return false;
>  }
> diff --git a/mm/slub.c b/mm/slub.c
> index d14226ad09822..2c5ba8c326e73 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
[ ... ]
> -static void free_empty_sheaf(struct kmem_cache *s, struct slab_sheaf *sheaf)
> +static void __free_empty_sheaf(struct kmem_cache *s, struct slab_sheaf *sheaf,
> +			       unsigned int free_flags)
>  {
[ ... ]
> +	if (unlikely(free_flags & SLAB_FREE_NOLOCK))
> +		kfree_nolock(sheaf);
> +	else
> +		kfree(sheaf);
>  
>  	stat(s, SHEAF_FREE);
>  }
>  
> +static void free_empty_sheaf(struct kmem_cache *s, struct slab_sheaf *sheaf)
> +{
> +	__free_empty_sheaf(s, sheaf, SLAB_FREE_DEFAULT);
> +}

[Severity: High]
Does this wrapper cause a kmemleak symmetry violation?

When __kfree_rcu_sheaf() is called with SLAB_FREE_NOLOCK, it allocates the
sheaf using SLAB_ALLOC_NOLOCK, which skips kmemleak registration.

However, the allocated sheaf struct does not track its allocation flags.
Later, when this sheaf is flushed or processed for freeing (e.g., via
rcu_free_sheaf()), free_empty_sheaf() is called unconditionally.

Because free_empty_sheaf() hardcodes SLAB_FREE_DEFAULT, it will call
kfree() instead of kfree_nolock() on an unregistered memory block. Could
this lead to kmemleak warnings and false positive memory leaks due to
freeing an unknown object?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-kfree_rcu_nolock-v5-0-a28cdcda9673@xxxxxxxxxx?part=2