From: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>,
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>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
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] slab: fix kmalloc_nolock() context check for PREEMPT_RT
Date: Fri, 19 Dec 2025 10:29:11 -0300 [thread overview]
Message-ID: <aUVTJyd74OoCtSyN@redhat.com> (raw)
In-Reply-To: <6fcfe0cc-3826-42c2-9c54-c127dc8379e1@suse.cz>
On Fri, Dec 19, 2025 at 10:31:55AM +0100, Vlastimil Babka wrote:
> On 12/19/25 09:57, 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.
> >
> > 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 also checking preempt_count() on PREEMPT_RT, ensuring
> > kmalloc_nolock() returns NULL early when called from any
> > non-preemptible context.
> >
> > 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>
> > ---
> > 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..1dd8a25664c5 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) && (in_nmi() || in_hardirq() || preempt_count() ))
>
> AFAICS we can just simplify that to preempt_count() then, since in_nmi() and
> in_hardirq() both are a special cases of that.
>
> Any comment from RT folks please?
Maybe, for the purpose of this change, using in_atomic() or !preemptible()
would be a bit more descriptive, as both macros check preempt_count()?
Luis
> > + /*
> > + * kmalloc_nolock() in PREEMPT_RT is not supported from
> > + * non-preemptible context because local_lock becomes a
> > + * sleeping lock on RT.
> > + */
> > return NULL;
> > retry:
> > if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
> >
> > base-commit: 559e608c46553c107dbba19dae0854af7b219400
> > --
> > 2.52.0
> >
>
>
---end quoted text---
next prev parent reply other threads:[~2025-12-19 13:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 8:57 [PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT Swaraj Gaikwad
2025-12-19 9:31 ` Vlastimil Babka
2025-12-19 13:29 ` Luis Claudio R. Goncalves [this message]
2025-12-19 13:51 ` Swaraj Gaikwad
2026-01-05 19:19 ` Vlastimil Babka
2026-01-13 13:59 ` Vlastimil Babka
2025-12-19 15:22 ` Hao Li
2025-12-19 18:02 ` Luis Claudio R. Goncalves
2025-12-19 15:52 ` 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=aUVTJyd74OoCtSyN@redhat.com \
--to=lgoncalv@redhat.com \
--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 \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.