Re: [PATCH v2] mm/slab: sample slab_state once in kmem_cache_destroy()

[Harry Yoo]

On Wed, Oct 14, 2026 at 05:08:43PM +0200, Imre Kaloz wrote:
> kmem_cache_release() tests slab_state >= FULL after kmem_cache_destroy()
> has dropped slab_mutex and unlinked the cache, and for a
> SLAB_TYPESAFE_BY_RCU cache after rcu_barrier(). If slab_late_init() runs
> before that test it sets slab_state to FULL but skips the unlinked cache,
> which never got a sysfs entry, so sysfs_slab_release() calls kobject_put()
> on a kobject that was never initialized:
> 
>   WARNING: lib/kobject.c:734 at kobject_put+0x64/0x2c0, CPU#1: kworker/u8:3/55
>   kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_put() is being called.
>   refcount_t: underflow; use-after-free.
>   kobject_put+0x64/0x2c0
>   sysfs_slab_release+0xc/0x20
>   kmem_cache_destroy+0x104/0x1e0
>   bioset_exit+0x13c/0x1e0
>   disk_release+0x54/0x140
>   put_disk+0x18/0x40
>   floppy_async_init+0xbec/0xd10
> 
> The release-time test has run outside slab_mutex since at least v4.4 for
> SLAB_TYPESAFE_BY_RCU caches, and since v6.0 for the others. Since v6.12
> the unlink-time test in kmem_cache_destroy() is a separate read of its
> own, also after mutex_unlock(), so the two can disagree. Both tests ask
> whether the cache has a kobject, which cache creation skips while
> slab_state <= UP. UP is the state just below FULL, so a false sample
> cannot skip a kobject_put() that was owed.
> 
> Seen on sparc64 at boot, where the asynchronous floppy init tears down
> its bio slab while the late initcalls are running.
> 
> Sample slab_state once, under slab_mutex which slab_late_init() holds
> when it sets FULL, and use the result for both the unlink and the
> release.
> 
> Fixes: d50d82faa0c9 ("slub: fix failure when we delete and create a slab cache")
> Fixes: 4ec10268ed98 ("mm, slab: unlink slabinfo, sysfs and debugfs immediately")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Imre Kaloz <kaloz@xxxxxxxxxx>
> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@xxxxxxxxx>
> ---

Looks good to me,
Reviewed-by: Harry Yoo (Meta) <harry@xxxxxxxxxx>

I guess it's late to queue this to slab/for-next-fixes.
Let's queue this to slab/for-next for 7.4-rc1.

-- 
Cheers,
Harry / Hyeonggon