Re: [PATCH] mm/slab: change stride type from unsigned short to unsigned int

[Hao Li <hao.li@linux.dev>]

On Wed, Mar 04, 2026 at 11:17:46AM +0100, Vlastimil Babka wrote:
> On 3/3/26 2:57 PM, Harry Yoo wrote:
> > Commit 7a8e71bc619d ("mm/slab: use stride to access slabobj_ext")
> > defined the type of slab->stride as unsigned short, because the author
> > initially planned to store stride within the lower 16 bits of the
> > page_type field, but later stored it in unused bits in the counters
> > field instead.
> > 
> > However, the idea of having only 2-byte stride turned out to be a
> > serious mistake. On systems with 64k pages, order-1 pages are 128k,
> > which is larger than USHRT_MAX. It triggers a debug warning because
> > s->size is 128k while stride, truncated to 2 bytes, becomes zero:
> > 
[...]
> > 
> > This leads to slab_obj_ext() returning the first slabobj_ext or all
> > objects and confuses the reference counting of object cgroups [1] and
> > memory (un)charging for memory cgroups [2].
> > 
> > Fortunately, the counters field has 32 unused bits instead of 16
> > on 64-bit CPUs, which is wide enough to hold any value of s->size.
> > Change the type to unsigned int.
> > 
> > Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> > Closes: https://lore.kernel.org/lkml/ca241daa-e7e7-4604-a48d-de91ec9184a5@linux.ibm.com [1]
> > Closes: https://lore.kernel.org/all/ddff7c7d-c0c3-4780-808f-9a83268bbf0c@linux.ibm.com [2]
> > Fixes: 7a8e71bc619d ("mm/slab: use stride to access slabobj_ext")
> > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> 
> Added to slab/for-next-fixes, thanks!
> Hopefully Venkat confirms the fix and we can close and try to forget
> about the memory ordering can of worms again ;)

Oh, by the way, for that earlier patch that added a memory barrier, the
reported testing results also show the issue no longer reproduces.[1]
So, could it just be that it didn't happen to reproduce that time?

[1] https://lore.kernel.org/linux-mm/84492f08-04c2-485c-9a18-cdafd5a9c3e5@linux.ibm.com/

> 
> > ---
> > 
> > Hi Venkat, could you please test this on top of 7.0-rc2 (instead of
> > 7.0-rc1) and see if the bugs [1] [2] are reproduced on your machine?
> > 
> > I reproduced a debug warning on a ppc machine and fixed it.
> > The bugs are expected to be resolved by this fix.
> > 
> > p.s. After more debugging, I saw stride appeared as 0 even on the CPU
> > that wrote it, which likely rules out a memory ordering issue...
> > and I discovered this while decoding ppc assembly suspecting memory
> > corruption or a compiler bug, which came down to:
> >   
> >     "Hmm... why is the size truncated to 2 bytes?... OH WAIT!"
> > 
> >  mm/slab.h | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
[...]