Re: [PATCH for-next v3 7/9] mm/slab: introduce kfree_rcu_nolock()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] kfree_call_rcu_nolock() crashes when freeing large kmalloc objects or vmalloc addresses due to an unconditional dereference of `slab->slab_cache`.
- [High] Calling `__kfree_rcu_sheaf()` on PREEMPT_RT triggers an 'Invalid wait context' lockdep warning because it attempts a `local_trylock()` under a `raw_spinlock_t`.
--

commit 8bccb182210df2707b079473bfa04aa463cafa86
Author: Harry Yoo (Oracle) <harry@xxxxxxxxxx>

mm/slab: introduce kfree_rcu_nolock()

This commit introduces kfree_rcu_nolock(), a variant of kfree_rcu() designed
to be safely called from unknown contexts without falling back to batched
processing. It primarily tries to use the sheaf path and falls back to
defer_kfree_rcu() if that fails.

> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 807924a94fb08..5a39e62251609 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1263,6 +1263,23 @@ EXPORT_TRACEPOINT_SYMBOL(kmem_cache_alloc);
>  EXPORT_TRACEPOINT_SYMBOL(kfree);
>  EXPORT_TRACEPOINT_SYMBOL(kmem_cache_free);
>  
> +void kfree_call_rcu_nolock(struct rcu_head *head, void *ptr)
> +{
> +	struct slab *slab;
> +	struct kmem_cache *s;
> +
> +	VM_WARN_ON_ONCE(is_vmalloc_addr(ptr) || !virt_to_slab(ptr));
> +
> +	slab = virt_to_slab(ptr);
> +	s = slab->slab_cache;

[Severity: Critical]
Does this crash when freeing large kmalloc objects or vmalloc addresses?

If ptr is a large kmalloc object (which bypasses SLUB) or a vmalloc address,
virt_to_slab(ptr) returns NULL. The code issues a VM_WARN_ON_ONCE but
proceeds to blindly dereference slab->slab_cache, causing a deterministic
NULL pointer dereference.

Standard kfree_rcu() and kvfree_rcu() support these types of addresses, so
callers might pass them here expecting them to be handled safely. Should we
return early or handle the fallback path directly if slab is NULL?

> +
> +	if (__kfree_rcu_sheaf(s, ptr, /* allow_spin = */ false))
> +		return;

[Severity: High]
Can this trigger an 'Invalid wait context' lockdep warning on PREEMPT_RT?

The purpose of kfree_call_rcu_nolock() is to handle unknown contexts,
including hardirq or raw spinlock contexts. However, this unconditionally
calls __kfree_rcu_sheaf(), which acquires a lock via
local_trylock(&s->cpu_sheaves->lock).

On PREEMPT_RT, local_lock maps to a sleepable spinlock_t (RT mutex).
Acquiring a sleepable lock inside a raw spinlock context causes a lockdep
splat because CONFIG_PROVE_RAW_LOCK_NESTING checks declared wait-types even
for trylocks.

> +
> +	defer_kfree_rcu(head);
> +}
> +EXPORT_SYMBOL_GPL(kfree_call_rcu_nolock);

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