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

[Harry Yoo]

On Tue, Oct 13, 2026 at 02:51:30PM +0200, Imre Kaloz wrote:
> Hi Harry,

Hi Imre,

> 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!

Thanks. It 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.

0495e337b703 Probably yes. Not 100% sure.

It's quite messy, reading slab_state has been done inside, switched
to outside, and back to inside, and so on.

But should be fine as long as we can find the first commit that
affects -stable kernels (>= 5.10.y)

> 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?

Could you please verify fixing which bugs resolves the issue on sparc64
described in the changelog? Reading it twice, or outside slab_mutex, or
both?

-- 
Cheers,
Harry / Hyeonggon