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

[Imre Kaloz <kaloz@kernel.org>]

Hi Harry,

On Thu, 15 Oct 2026, Harry Yoo wrote:

> On Thu, Oct 15, 2026 at 09:21:43AM +0200, Vlastimil Babka (SUSE) wrote:
>> On 10/14/26 17:08, 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
>>
>> It would be useful to mention the commits here along with the versions. Also
>> this suggests 3 commits but there's only 2 in Fixes.
>
> Agreed.
>
> At second look I think we should improve the changelog a bit....
> And the history of this race is really... messy.
>
> I'll just rewrite this part a little bit with specific commits and
> add Fixes: tags for each commit that introduced for re-introduced
> the commit, along with some history so that people* can decide whether
> they* should pick this up.
>
> *who may maintain downstream stable Linux kernels
>
>>> the unlink-time test in kmem_cache_destroy() is a separate read of its
>>> own, also after mutex_unlock(), so the two can disagree.
>
> This part is unnecessary because reading slab_state outside
> slab_mutex is what we should fix. As long as it's read under
> slab_mutex, reading it once or twice doesn't really matter.
>
> (See full changelog at the end of this email)
>
>> I would guess the 6.0 change is not a crucial one?
>
> Uh, I thought the Fixes: was 6.0 one, not 6.12 one :/
>
>> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>
> Thanks!
>
> So... below is my suggestion. What do you think?

<snip>

Looks good to me, thanks for untangling all of that history.


Best,
Imre