Re: [PATCH RFC 2/4] mm/slab: handle allow_spin in slab_free_hook() instead of open coding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] slab_free_hook() proceeds with an unsafe GFP_NOWAIT allocation after VM_WARN_ON_ONCE(!allow_spin) for SLAB_TYPESAFE_BY_RCU caches, deadlocking NMI callers.
--

commit b732dfb9de7b44943319ed866b71dd254fecb07a
Author: Harry Yoo (Oracle) <harry@kernel.org>

mm/slab: handle allow_spin in slab_free_hook() instead of open coding

This commit refactors slab_free_hook() to accept an allow_spin parameter,
replacing the open-coded hook logic in memcg_alloc_abort_single() and
kfree_nolock(). It ensures that spinlock-acquiring free hooks and KASAN
quarantine operations are bypassed when allow_spin is false.

> diff --git a/mm/slub.c b/mm/slub.c
> index 32672a92581b0..85760c8ff2e29 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c

[ ... ]

> @@ -2654,6 +2665,7 @@ bool slab_free_hook(struct kmem_cache *s, void *x, bool init,
>  	if (still_accessible) {
>  		struct rcu_delayed_free *delayed_free;
>  
> +		VM_WARN_ON_ONCE(!allow_spin);
>  		delayed_free = kmalloc_obj(*delayed_free, GFP_NOWAIT);

[Severity: High]
If allow_spin is false (e.g., when called from kfree_nolock() in NMI or
atomic context), this triggers the warning but still proceeds to call
kmalloc_obj() with GFP_NOWAIT.

Since GFP_NOWAIT does not prevent the slab allocator from acquiring spinlocks
(such as pcp->lock or node->list_lock), and it does not strip
__GFP_KSWAPD_RECLAIM which can wake kswapd and acquire scheduler locks, could
this lead to a deadlock if called in NMI context?

Should this path explicitly skip the allocation or return early when
allow_spin is false?

>  		if (delayed_free) {
>  			/*
>  			 * Let KASAN track our call stack as a "related work

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-kmalloc-nolock-fixes-v1-0-fdf4d17351dd@kernel.org?part=2