From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
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: Tue, 13 Jan 2026 19:00:36 +0100 [thread overview]
Message-ID: <20260113180036.Zl8j3vIY@linutronix.de> (raw)
In-Reply-To: <20260113150639.48407-1-swarajgaikwad1925@gmail.com>
On 2026-01-13 20:36:39 [+0530], Swaraj Gaikwad wrote:
> On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current
> check in kmalloc_nolock() only verifies we're not in NMI or hard IRQ
> context, but misses the case where preemption is disabled.
The reasoning was different back then.
> When a BPF program runs from a tracepoint with preemption disabled
> (preempt_count > 0), kmalloc_nolock() proceeds to call
> local_lock_irqsave() which attempts to acquire a sleeping lock,
> triggering:
>
> BUG: sleeping function called from invalid context
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128
> preempt_count: 2, expected: 0
>
> Fix this by checking !preemptible() on PREEMPT_RT, which directly
> expresses the constraint that we cannot take a sleeping lock when
> preemption is disabled. This encompasses the previous checks for NMI
> and hard IRQ contexts while also catching cases where preemption is
> disabled.
>
> Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")
> Reported-by: syzbot+b1546ad4a95331b2101e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=b1546ad4a95331b2101e
> Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
> ---
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
for now.
> Changes in v2:
> - Simplified condition from (in_nmi() || in_hardirq() || preempt_count())
> to !preemptible() as suggested by Luis Claudio R. Goncalves and agreed
> by Vlastimil Babka
> - Updated comment to reflect the more descriptive check
>
> Tested by building with syz config and running the syzbot
> reproducer - kernel no longer crashes.
>
> mm/slub.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 2acce22590f8..642f4744d5c6 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5689,8 +5689,12 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node)
> if (unlikely(!size))
> return ZERO_SIZE_PTR;
>
> - if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
> - /* kmalloc_nolock() in PREEMPT_RT is not supported from irq */
> + if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible())
> + /*
> + * kmalloc_nolock() in PREEMPT_RT is not supported from
> + * non-preemptible context because local_lock becomes a
> + * sleeping lock on RT.
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?
> + */
> return NULL;
> retry:
> if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
>
Sebastian
prev parent reply other threads:[~2026-01-13 18:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 15:06 Swaraj Gaikwad
2026-01-13 18:00 ` Sebastian Andrzej Siewior [this message]
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=20260113180036.Zl8j3vIY@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--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 \
--cc=vbabka@suse.cz \
/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