Re: [PATCH V5 8/8] mm/slab: place slabobj_ext metadata in unused space within s->size

[Vlastimil Babka <vbabka@suse.cz>]

On 1/8/26 11:44, Harry Yoo wrote:
> On Thu, Jan 08, 2026 at 05:52:27PM +0800, Hao Li wrote:
>> On Thu, Jan 08, 2026 at 05:41:00PM +0900, Harry Yoo wrote:
>> > On Thu, Jan 08, 2026 at 01:52:09PM +0800, Hao Li wrote:
>> > > On Mon, Jan 05, 2026 at 05:02:30PM +0900, Harry Yoo wrote:
>> > > > When a cache has high s->align value and s->object_size is not aligned
>> > > > to it, each object ends up with some unused space because of alignment.
>> > > > If this wasted space is big enough, we can use it to store the
>> > > > slabobj_ext metadata instead of wasting it.
>> > > 
>> > > Hi, Harry,
>> > 
>> > Hi Hao,
>> > 
>> > > When we save obj_ext in s->size space, it seems that slab_ksize() might
>> > > be missing the corresponding handling.
>> > 
>> > Oops.
>> > 
>> > > It still returns s->size, which could cause callers of slab_ksize()
>> > > to see unexpected data (i.e. obj_ext), or even overwrite the obj_ext data.
>> > 
>> > Yes indeed.
>> > Great point, thanks!
>> > 
>> > I'll fix it by checking if the slab has obj_exts within the object
>> > layout and returning s->object_size if so.
>> 
>> Makes sense - I think there's one more nuance worth capturing.
>> slab_ksize() seems to compute the maximum safe size by applying layout
>> constraints from most-restrictive to least-restrictive:
>> redzones/poison/KASAN clamp it to object_size, tail metadata
>> (SLAB_TYPESAFE_BY_RCU / SLAB_STORE_USER) clamps it to inuse, and only
>> when nothing metadata lives does it return s->size.
> 
> Waaaait, SLAB_TYPESAFE_BY_RCU isn't the only case where we put freelist
> pointer after the object.
> 
> What about caches with constructor?
> We do place it after object, but slab_ksize() may return s->size? 

I think the freelist pointer is fine because it's not used by allocated objects?
Also ksize() should no longer be used to fill more of the object than that
was requested in the first place.