linux-kernel - Re: [PATCH RFC v2 06/20] slab: make percpu sheaves compatible with kmalloc_nolock()/kfree

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: <d0f5f72d-77de-4be7-990c-a5e47f326dd9@suse.cz>
Date: Thu, 15 Jan 2026 12:07:03 +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 06/20] slab: make percpu sheaves compatible with
 kmalloc_nolock()/kfree_nolock()

On 1/13/26 16:42, Hao Li wrote:
>> @@ -6129,6 +6152,17 @@ __pcs_replace_full_main(struct kmem_cache *s, struct slub_percpu_sheaves *pcs)
>>  		return pcs;
>>  	}
>>  
>> +	if (!allow_spin) {
>> +		/*
>> +		 * sheaf_flush_unused() or alloc_empty_sheaf() don't support
>> +		 * !allow_spin and instead of trying to support them it's
>> +		 * easier to fall back to freeing the object directly without
>> +		 * sheaves
>> +		 */
>> +		local_unlock(&s->cpu_sheaves->lock);
>> +		return NULL;
>> +	}
> 
> It looks like when "allow_spin" is false, __pcs_replace_full_main() can
> still end up calling alloc_empty_sheaf() if pcs->spare is NULL (via the

Oops your're right, we can't allow that. Thanks!

> "goto alloc_empty" path). Would it make sense to bail out a bit earlier
> in that case?

I've reorganized the code a bit so it shouldn't happen anymore.