[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260113180036.Zl8j3vIY@linutronix.de>
Date: Tue, 13 Jan 2026 19:00:36 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Swaraj Gaikwad <swarajgaikwad1925@...il.com>
Cc: Vlastimil Babka <vbabka@...e.cz>,
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 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@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=b1546ad4a95331b2101e
> Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@...il.com>
> ---
Acked-by: Sebastian Andrzej Siewior <bigeasy@...utronix.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
Powered by blists - more mailing lists