linux-kernel - Re: [PATCH RFC v2 03/20] mm/slab: make caches with sheaves mergeable

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: <CAJuCfpHowLbqn7ex1COBTZBchhWFy=C3sgD0Uo=J-nKX+NYBvA@mail.gmail.com>
Date: Fri, 16 Jan 2026 00:22:42 +0000
From: Suren Baghdasaryan <surenb@...gle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Harry Yoo <harry.yoo@...cle.com>, Petr Tesarik <ptesarik@...e.com>, 
	Christoph Lameter <cl@...two.org>, David Rientjes <rientjes@...gle.com>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Hao Li <hao.li@...ux.dev>, 
	Andrew Morton <akpm@...ux-foundation.org>, Uladzislau Rezki <urezki@...il.com>, 
	"Liam R. Howlett" <Liam.Howlett@...cle.com>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, 
	Alexei Starovoitov <ast@...nel.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	linux-rt-devel@...ts.linux.dev, bpf@...r.kernel.org, 
	kasan-dev@...glegroups.com
Subject: Re: [PATCH RFC v2 03/20] mm/slab: make caches with sheaves mergeable

On Mon, Jan 12, 2026 at 3:17 PM Vlastimil Babka <vbabka@...e.cz> wrote:
>
> Before enabling sheaves for all caches (with automatically determined
> capacity), their enablement should no longer prevent merging of caches.
> Limit this merge prevention only to caches that were created with a
> specific sheaf capacity, by adding the SLAB_NO_MERGE flag to them.
>
> Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
> ---
>  mm/slab_common.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 52591d9c04f3..54c17dc6d5ec 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -163,9 +163,6 @@ int slab_unmergeable(struct kmem_cache *s)
>                 return 1;
>  #endif
>
> -       if (s->cpu_sheaves)
> -               return 1;
> -
>         /*
>          * We may have set a slab to be unmergeable during bootstrap.
>          */
> @@ -190,9 +187,6 @@ static struct kmem_cache *find_mergeable(unsigned int size, slab_flags_t flags,
>         if (IS_ENABLED(CONFIG_HARDENED_USERCOPY) && args->usersize)
>                 return NULL;
>
> -       if (args->sheaf_capacity)
> -               return NULL;
> -
>         flags = kmem_cache_flags(flags, name);
>
>         if (flags & SLAB_NEVER_MERGE)
> @@ -337,6 +331,13 @@ struct kmem_cache *__kmem_cache_create_args(const char *name,
>         flags &= ~SLAB_DEBUG_FLAGS;
>  #endif
>
> +       /*
> +        * Caches with specific capacity are special enough. It's simpler to
> +        * make them unmergeable.
> +        */
> +       if (args->sheaf_capacity)
> +               flags |= SLAB_NO_MERGE;

So, this is very subtle and maybe not that important but the comment
for kmem_cache_args.sheaf_capacity claims "When slub_debug is enabled
for the cache, the sheaf_capacity argument is ignored.". With this
change this argument is not completely ignored anymore... It sets
SLAB_NO_MERGE even if slub_debug is enabled, doesn't it?

> +
>         mutex_lock(&slab_mutex);
>
>         err = kmem_cache_sanity_check(name, object_size);
>
> --
> 2.52.0
>