linux-kernel - Re: [PATCH RFC 14/19] slab: simplify kmalloc

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: <4fca7893-60bd-41da-844f-971934de19b6@suse.cz>
Date: Fri, 9 Jan 2026 11:11:26 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Hao Li <hao.li@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Christoph Lameter <cl@...two.org>, David Rientjes <rientjes@...gle.com>,
 Roman Gushchin <roman.gushchin@...ux.dev>, Harry Yoo <harry.yoo@...cle.com>,
 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 14/19] slab: simplify kmalloc_nolock()

On 12/16/25 03:35, Hao Li wrote:
> On Thu, Oct 23, 2025 at 03:52:36PM +0200, Vlastimil Babka wrote:
>> @@ -5214,27 +5144,13 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node)
>>  	if (ret)
>>  		goto success;
>>  
>> -	ret = ERR_PTR(-EBUSY);
>> -
>>  	/*
>>  	 * Do not call slab_alloc_node(), since trylock mode isn't
>>  	 * compatible with slab_pre_alloc_hook/should_failslab and
>>  	 * kfence_alloc. Hence call __slab_alloc_node() (at most twice)
>>  	 * and slab_post_alloc_hook() directly.
>> -	 *
>> -	 * In !PREEMPT_RT ___slab_alloc() manipulates (freelist,tid) pair
>> -	 * in irq saved region. It assumes that the same cpu will not
>> -	 * __update_cpu_freelist_fast() into the same (freelist,tid) pair.
>> -	 * Therefore use in_nmi() to check whether particular bucket is in
>> -	 * irq protected section.
>> -	 *
>> -	 * If in_nmi() && local_lock_is_locked(s->cpu_slab) then it means that
>> -	 * this cpu was interrupted somewhere inside ___slab_alloc() after
>> -	 * it did local_lock_irqsave(&s->cpu_slab->lock, flags).
>> -	 * In this case fast path with __update_cpu_freelist_fast() is not safe.
>>  	 */
>> -	if (!in_nmi() || !local_lock_is_locked(&s->cpu_slab->lock))
>> -		ret = __slab_alloc_node(s, alloc_gfp, node, _RET_IP_, size);
>> +	ret = __slab_alloc_node(s, alloc_gfp, node, _RET_IP_, size);
>>  
>>  	if (PTR_ERR(ret) == -EBUSY) {
> 
> After Patch 10 is applied, the logic that returns `EBUSY` has been
> removed along with the `s->cpu_slab` logic. As a result, it appears that
> `__slab_alloc_node` will no longer return `EBUSY`.

True, I missed that, thanks.
Since we can still get failures due to the cpu_sheaves local lock held, I
think we could just do the single retry with a larger bucket if ret is NULL.
Whlle it may be NULL for other reasons (being genuinely out of memory and
the limited context not allowing reclaim etc), it wouldn't hurt, and it's
better than to introduce returning EBUSY into various paths.

>>  		if (can_retry) {
>> @@ -7250,10 +7166,6 @@ void __kmem_cache_release(struct kmem_cache *s)
>>  {
>>  	cache_random_seq_destroy(s);
>>  	pcs_destroy(s);
>> -#ifdef CONFIG_PREEMPT_RT
>> -	if (s->cpu_slab)
>> -		lockdep_unregister_key(&s->lock_key);
>> -#endif
>>  	free_percpu(s->cpu_slab);
>>  	free_kmem_cache_nodes(s);
>>  }
>> 
>> -- 
>> 2.51.1
>>