Re: [PATCH 1/2] mm/slab: allow freeing kmalloc_nolock()'d objects using kfree[_rcu]()

[Catalin Marinas <catalin.marinas@arm.com>]

On Mon, Feb 09, 2026 at 09:10:12PM +0900, Harry Yoo wrote:
> Slab objects that are allocated with kmalloc_nolock() must be freed
> using kfree_nolock() because only a subset of alloc hooks are called,
> since kmalloc_nolock() can't spin on a lock during allocation.
> 
> This imposes a limitation: such objects cannot be freed with kfree_rcu(),
> forcing users to work around this limitation by calling call_rcu()
> with a callback that frees the object using kfree_nolock().
> 
> Remove this limitation by teaching kmemleak to gracefully ignore cases
> when kmemleak_free() or kmemleak_ignore() (called by kvfree_call_rcu())
> is called without a prior kmemleak_alloc().
> 
> Unlike kmemleak, kfence already handles this case, because,
> due to its design, only a subset of allocations are served from kfence.
> 
> With this change, kfree() and kfree_rcu() can be used to free objects
> that are allocated using kmalloc_nolock().
> 
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>

It looks fine to me. The alternative would have been to track objects
allocated by kmalloc_nolock() but that's not (easily) possible without
taking more locks in kmemleak.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>