linux-kernel - Re: [RFC PATCH V3 6/7] mm/slab: save memory by allocating slabobj

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: <48029aab-20ea-4d90-bfd1-255592b2018e@suse.cz>
Date: Thu, 30 Oct 2025 17:33:30 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Harry Yoo <harry.yoo@...cle.com>, Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, andreyknvl@...il.com, cl@...ux.com,
 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, vincenzo.frascino@....com, yeoreum.yun@....com,
 tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V3 6/7] mm/slab: save memory by allocating slabobj_ext
 array from leftover

On 10/30/25 01:40, Harry Yoo wrote:
> On Wed, Oct 29, 2025 at 11:37:27AM -0700, Suren Baghdasaryan wrote:
>> > > >         mod_node_page_state(slab_pgdat(slab), cache_vmstat_idx(s),
>> > > > @@ -3219,9 +3352,6 @@ static struct slab *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
>> > > >         slab->objects = oo_objects(oo);slab_obj_exts
>> > > >         slab->inuse = 0;
>> > > >         slab->frozen = 0;
>> > > > -       init_slab_obj_exts(slab);
>> > > > -
>> > > > -       account_slab(slab, oo_order(oo), s, flags);
>> > > >
>> > > >         slab->slab_cache = s;
>> > > >
>> > > > @@ -3230,6 +3360,13 @@ static struct slab *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
>> > > >         start = slab_address(slab);
>> > > >
>> > > >         setup_slab_debug(s, slab, start);
>> > > > +       init_slab_obj_exts(slab);
>> > > > +       /*
>> > > > +        * Poison the slab before initializing the slabobj_ext array
>> > > > +        * to prevent the array from being overwritten.
>> > > > +        */
>> > > > +       alloc_slab_obj_exts_early(s, slab);
>> > > > +       account_slab(slab, oo_order(oo), s, flags);
>> > >
>> > >  alloc_slab_obj_exts() is called in 2 other places:
>> > > 1. __memcg_slab_post_alloc_hook()
>> > > 2. prepare_slab_obj_exts_hook()
>> > >
>> > > Don't you need alloc_slab_obj_exts_early() there as well?
>> >
>> > That's good point, and I thought it's difficult to address
>> > concurrency problem without using a per-slab lock.
>> >
>> > Thread A                    Thread B
>> > - sees slab->obj_exts == 0
>> >                             - sees slab->obj_exts == 0
>> >                             - allocates the vector from unused space
>> >                               and initializes it.
>> >                             - try cmpxchg()
>> > - allocates the vector
>> >   from unused space and
>> >   initializes it.
>> >   (the vector is already
>> >    in use and it's overwritten!)
>> >
>> > - try cmpxchg()
>> >
>> > But since this is slowpath, using slab_{lock,unlock}() here is probably
>> > fine. What do you think?
>> 
>> Ok, was your original intent to leave these callers as is and allocate
>> the vector like we do today even if obj_exts fit inside the slab?
> 
> Yes that's what I intended, and maybe later we could allocate the vector
> from the unused space even after the slab is allocated, as long as
> it doesn't hurt performance.

It would be nice. I guess what can happen is there's a cache without
SLAB_ACCOUNT but then some allocations from that will use __GFP_ACCOUNT and
we need to allocate obj_exts on-demand, right?

>> >
>> > --
>> > Cheers,
>> > Harry / Hyeonggon
>