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

[Imre Kaloz]

Hi Harry,

On Tue, 13 Oct 2026, Harry Yoo wrote:

> Uh, apologies for the late reply.
> Catching up after trip at LPC...

No worries, hope LPC was good!

> On Thu, Oct 01, 2026 at 05:42:36PM +0200, Imre Kaloz wrote:

<snip>

> > There is a related older window: after list_del() and before that
> > single read, slab_sysfs_init() could set FULL, skip this cache, and
> > the single read would then call both unlink and release on an
> > uninitialized kobject.
>
> No, with this patch slab_sysfs_init() cannot set the state to FULL
> because the slab_caches list and slab_state are protected by slab_mutex.
>
> > I have not hit that, and this patch does not close it.
>
> I think the patch does close two bugs.
>
> One introduced by 4ec10268ed98 (reading slab_state twice),
> another (reading slab_state outside slab_mutex) introduced by, hmm,
> not sure which commit introduced it :) should be very old.

You're right, I got that one wrong. Sampling under slab_mutex in the
same section as the list_del() means slab_late_init() either sees the
cache on the list or we see slab_state < FULL, so the older window is
closed too.

As for where the outside-mutex read came from, as far as I can tell it's
0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy()
without holding slab_mutex/cpu_hotplug_lock"). Before that, the unlink
and release and their slab_state checks ran in shutdown_cache() under
slab_mutex. SLAB_TYPESAFE_BY_RCU caches were already released from the
workfn outside the mutex since 657dc2f97220.

Want me to send a v2 with a second Fixes: for 0495e337b703, or is it
fine to add it when applying?


Best,
Imre