linux-kernel - Re: [PATCH RFC v2 09/20] slab: remove cpu (partial) slabs usage from allocation paths

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: <3aa7a303-677d-4ef5-8df1-b3c0fdfcc787@suse.cz>
Date: Thu, 15 Jan 2026 14:53:36 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Hao Li <hao.li@...ux.dev>
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>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Uladzislau Rezki <urezki@...il.com>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Suren Baghdasaryan <surenb@...gle.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 09/20] slab: remove cpu (partial) slabs usage from
 allocation paths

On 1/14/26 07:07, Hao Li wrote:
>> @@ -4836,68 +4558,31 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
>>  	if (IS_ENABLED(CONFIG_SLUB_TINY) || kmem_cache_debug(s)) {
>>  		freelist = alloc_single_from_new_slab(s, slab, orig_size, gfpflags);
>>  
>> -		if (unlikely(!freelist)) {
>> -			/* This could cause an endless loop. Fail instead. */
>> -			if (!allow_spin)
>> -				return NULL;
>> -			goto new_objects;
>> +		if (likely(freelist)) {
>> +			goto success;
>>  		}
>> +	} else {
>> +		alloc_from_new_slab(s, slab, &freelist, 1, allow_spin);
> 
> IIUC, when CONFIG_SLUB_DEBUG is enabled, each successful new_slab() call
> should have a matching inc_slabs_node(), since __kmem_cache_shutdown()
> rely on the accounting done by inc_slabs_node(). Here
> alloc_single_from_new_slab() does call inc_slabs_node(), but
> alloc_from_new_slab() doesn't. Could this mismatch cause any issues?

Great spot, thanks a lot! Yes we should do inc_slabs_node() here.

>>  
>> -		if (s->flags & SLAB_STORE_USER)
>> -			set_track(s, freelist, TRACK_ALLOC, addr,
>> -				  gfpflags & ~(__GFP_DIRECT_RECLAIM));
>> -
>> -		return freelist;
>> -	}
>> -
>> -	/*
>> -	 * No other reference to the slab yet so we can
>> -	 * muck around with it freely without cmpxchg
>> -	 */
>> -	freelist = slab->freelist;
>> -	slab->freelist = NULL;
>> -	slab->inuse = slab->objects;
>> -	slab->frozen = 1;
>> -