Re: [PATCH v5] mm/slub: defer freelist construction until after bulk allocation from a new slab

[<hu.shengming@zte.com.cn>]

Harry wrote:
> On Mon, Apr 13, 2026 at 01:14:23PM +0800, hu.shengming@zte.com.cn wrote:
> > Harry wrote:
> > > On Thu, Apr 09, 2026 at 08:43:52PM +0800, hu.shengming@zte.com.cn wrote:
> > > > From: Shengming Hu <hu.shengming@zte.com.cn>
> > > > [...]
> > > > -    inc_slabs_node(s, nid, slab->objects);
> > > >      spin_unlock_irqrestore(&n->list_lock, flags);
> > > >  
> > > > +    inc_slabs_node(s, slab_nid(slab), slab->objects);
> > > 
> > > Ouch, I didn't catch this when it was added in v4. When slab debugging
> > > feature is enabled for the cache, inc_slabs_node() should be done within
> > > the spinlock to avoid race conditions with slab validation.
> > > 
> > > Perhaps it's worth adding a comment mentioning this :)
> > > 
> > > See commit c7323a5ad078 ("mm/slub: restrict sysfs validation to debug
> > > caches and make it safe") for more details.
> > > 
> > > With this fixed, please feel free to add:
> > > Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org>
> > > 
> > 
> > You are right about the inc_slabs_node() placement. I missed that change when
> > it was introduced in v4. Thank you very much for catching it.
> > 
> > After reading commit c7323a5ad078 ("mm/slub: restrict sysfs validation to debug
> > caches and make it safe"), my understanding is that inc_slabs_node() should
> > remain under n->list_lock for debug caches, so that validation cannot observe
> > inconsistent state during list transitions. I will fix that in the next revision
> > and add a comment along these lines.
> > 
> > Would a comment like the following look good? :-)
> > 
> > /*
> >  * Debug caches require nr_slabs updates under n->list_lock so validation
> >  * cannot race with list transitions and observe inconsistent state.
> >  */
> 
> Mostly LGTM, but perhaps it's better to say
> "validation cannot race with slab (de)allocations"
> because it's not about transitions between lists,
> but rather about slabs being added to or removed from the node while
> validation code is iterating over partial and full lists.
> 
> Thanks!
> 

Thanks, that makes sense.

You're right that the issue is better described in terms of slab
(de)allocations rather than list transitions.

I'll update the comment.

--
Cheers,
Shengming