From: Vlastimil Babka <vbabka@suse.cz>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Harry Yoo <harry.yoo@oracle.com>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Alexei Starovoitov <ast@kernel.org>,
"open list:SLAB ALLOCATOR" <linux-mm@kvack.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:Real-time Linux (PREEMPT_RT):Keyword:PREEMPT_RT"
<linux-rt-devel@lists.linux.dev>,
skhan@linuxfoundation.org, david.hunter.linux@gmail.com,
syzbot+b1546ad4a95331b2101e@syzkaller.appspotmail.com
Subject: Re: [PATCH v2] slab: fix kmalloc_nolock() context check for PREEMPT_RT
Date: Wed, 14 Jan 2026 14:14:28 +0100 [thread overview]
Message-ID: <f5cc5a84-57fc-4fd4-aa74-fc89fdcbb042@suse.cz> (raw)
In-Reply-To: <20260113180036.Zl8j3vIY@linutronix.de>
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
next prev parent reply other threads:[~2026-01-14 13:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 15:06 Swaraj Gaikwad
2026-01-13 18:00 ` Sebastian Andrzej Siewior
2026-01-13 23:34 ` Alexei Starovoitov
2026-01-14 13:14 ` Vlastimil Babka [this message]
2026-01-14 1:18 ` Harry Yoo
2026-01-14 14:27 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f5cc5a84-57fc-4fd4-aa74-fc89fdcbb042@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=cl@gentwo.org \
--cc=clrkwllms@kernel.org \
--cc=david.hunter.linux@gmail.com \
--cc=harry.yoo@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.org \
--cc=swarajgaikwad1925@gmail.com \
--cc=syzbot+b1546ad4a95331b2101e@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox