Re: [PATCH RFC 4/4] mm/slab: serialize defer_free_barrier()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Skipping offline CPUs in defer_free_barrier() causes a Use-After-Free when an offline CPU resumes and processes stranded defer_free_objects.
--

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

mm/slab: serialize defer_free_barrier()

This commit addresses a potential hang in defer_free_barrier() by executing
it under slab_mutex and cpus_read_lock(). It also changes the iteration
from for_each_possible_cpu() to for_each_online_cpu() since the lock
is now held.

Closes: https://sashiko.dev/#/patchset/20260615-kfree_rcu_nolock-v3-0-70a54f3775bb%40kernel.org?part=5

> diff --git a/mm/slub.c b/mm/slub.c
> index 4a3618e3967ed..52c8d3f337827 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -6411,7 +6411,11 @@ void defer_free_barrier(void)
>  {
>  	int cpu;
>  
> -	for_each_possible_cpu(cpu)
> +	/* irq_work_sync() may use rcuwait that requires serialization */
> +	lockdep_assert_held(&slab_mutex);
> +	lockdep_assert_cpus_held();
> +
> +	for_each_online_cpu(cpu)

[Severity: High]
By changing this to for_each_online_cpu(), does this skip offline CPUs
that might still hold pending deferred free objects?

If kfree_nolock() is called during CPU teardown after smpboot_park_threads()
or from a late NMI on an offline CPU, the defer_free work could remain
stranded on the offline CPU's lazy_list.

Because kmem_cache_destroy() would now skip waiting for these offline CPUs,
it could successfully destroy the cache while objects are still queued.

When the CPU is eventually brought back online, wouldn't the resumed CPU
process the stranded objects in free_deferred_objects() and dereference the
already destroyed cache?

mm/slub.c:free_deferred_objects() {
    ...
        s = slab->slab_cache;
        ...
        set_freepointer(s, x, NULL);
        __slab_free(s, slab, x, x, 1, _THIS_IP_);
    ...
}

> +		irq_work_sync(&per_cpu_ptr(&defer_free_objects, cpu)->work);
>  }
>

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