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

[Imre Kaloz]

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@xxxxxxxxxx>
>
> Thanks!
>
> So... below is my suggestion. What do you think?

<snip>

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


Best,
Imre