linux-kernel - Re: [PATCH v2] slab: fix kmalloc_nolock() context check for PREEMPT

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: <f5cc5a84-57fc-4fd4-aa74-fc89fdcbb042@suse.cz>
Date: Wed, 14 Jan 2026 14:14:28 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Swaraj Gaikwad <swarajgaikwad1925@...il.com>
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>,
 Clark Williams <clrkwllms@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
 Alexei Starovoitov <ast@...nel.org>,
 "open list:SLAB ALLOCATOR" <linux-mm@...ck.org>,
 open list <linux-kernel@...r.kernel.org>,
 "open list:Real-time Linux (PREEMPT_RT):Keyword:PREEMPT_RT"
 <linux-rt-devel@...ts.linux.dev>, skhan@...uxfoundation.org,
 david.hunter.linux@...il.com,
 syzbot+b1546ad4a95331b2101e@...kaller.appspotmail.com
Subject: Re: [PATCH v2] slab: fix kmalloc_nolock() context check for
 PREEMPT_RT

On 1/13/26 19:00, Sebastian Andrzej Siewior wrote:
> 
> I would say that despite the _nolock() suffix a local_lock() is still
> acquired. The !PREEMPT_RT does a trylock.
> 
> As I noticed this myself today while looking at other patches, was the
> trylock removed on RT by accident, was it there only in an earlier
> version which was never merged and will it ever come back so we can go
> back to !nmi || !hardirq?

IIRC there was no version that would do always a trylock on RT (or maybe
there was some early one but run into trouble quickly?). The problem was
converting the slub code to deal with situations where initially trylock
suceeds in the given context, but then it's dropped and later needed again,
and failing that later trylock would be too complex to unwind. So instead we
do the local_lock_is_locked() check upfront and then trust that all nested
local_lock_cpu_slab()'s can't fail. And unfortunately this doesn't very play
well with RT semantics.

> 
>> +		 */
>>  		return NULL;
>>  retry:
>>  	if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
>> 
> 
> Sebastian