linux-kernel - Re: [PATCH V6 9/9] mm/slab: place slabobj_ext metadata in unused space within s->size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWZCHIYsFSaGzRYu@hyeyoo>
Date: Tue, 13 Jan 2026 22:01:16 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: akpm@...ux-foundation.org, andreyknvl@...il.com, cl@...two.org,
        dvyukov@...gle.com, glider@...gle.com, hannes@...xchg.org,
        linux-mm@...ck.org, mhocko@...nel.org, muchun.song@...ux.dev,
        rientjes@...gle.com, roman.gushchin@...ux.dev, ryabinin.a.a@...il.com,
        shakeel.butt@...ux.dev, surenb@...gle.com, vincenzo.frascino@....com,
        yeoreum.yun@....com, tytso@....edu, adilger.kernel@...ger.ca,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        cgroups@...r.kernel.org, hao.li@...ux.dev
Subject: Re: [PATCH V6 9/9] mm/slab: place slabobj_ext metadata in unused
 space within s->size

On Tue, Jan 13, 2026 at 01:50:31PM +0100, Vlastimil Babka wrote:
> On 1/13/26 7:18 AM, 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.
> > 
> > On my system, this happens with caches like kmem_cache, mm_struct, pid,
> > task_struct, sighand_cache, xfs_inode, and others.
> > 
> > To place the slabobj_ext metadata within each object, the existing
> > slab_obj_ext() logic can still be used by setting:
> > 
> >   - slab->obj_exts = slab_address(slab) + (slabobj_ext offset)
> >   - stride = s->size
> > 
> > slab_obj_ext() doesn't need know where the metadata is stored,
> > so this method works without adding extra overhead to slab_obj_ext().
> > 
> > A good example benefiting from this optimization is xfs_inode
> > (object_size: 992, align: 64). To measure memory savings, 2 millions of
> > files were created on XFS.
> > 
> > [ MEMCG=y, MEM_ALLOC_PROFILING=n ]
> > 
> > Before patch (creating ~2.64M directories on xfs):
> >   Slab:            5175976 kB
> >   SReclaimable:    3837524 kB
> >   SUnreclaim:      1338452 kB
> > 
> > After patch (creating ~2.64M directories on xfs):
> >   Slab:            5152912 kB
> >   SReclaimable:    3838568 kB
> >   SUnreclaim:      1314344 kB (-23.54 MiB)
> > 
> > Enjoy the memory savings!
> > 
> > Suggested-by: Vlastimil Babka <vbabka@...e.cz>
> > Signed-off-by: Harry Yoo <harry.yoo@...cle.com>
> 
> Does this look OK to you or was there a reason you didn't do it? :)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index ba15df4ca417..deb69bd9646a 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -981,8 +981,7 @@ static inline bool obj_exts_in_slab(struct kmem_cache *s, struct slab *slab)
>  #if defined(CONFIG_SLAB_OBJ_EXT) && defined(CONFIG_64BIT)
>  static bool obj_exts_in_object(struct kmem_cache *s, struct slab *slab)
>  {
> -       return obj_exts_in_slab(s, slab) &&
> -              (slab_get_stride(slab) == s->size);
> +       return obj_exts_in_slab(s, slab) && (s->flags & SLAB_OBJ_EXT_IN_OBJ);

There was a reason why I didn't do it :)

In alloc_slab_obj_exts_early(), when both
obj_exts_fit_within_slab_leftover() and (s->flags & SLAB_OBJ_EXT_IN_OBJ)
returns true, it allocates the metadata from the slab's leftover space.

I noticed it as I saw a slab error in slab_pad_check() complaining that
the padding area was overwritten, but turned out the problem was
because obj_exts_in_object() returning true when it shouldn't.

>  }
>  
>  static unsigned int obj_exts_offset_in_object(struct kmem_cache *s)

-- 
Cheers,
Harry / Hyeonggon