[PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[Swaraj Gaikwad]

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() ))
+		/*
+		 * 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

Re: [PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[Vlastimil Babka]

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?

> +		/*
> +		 * 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
> 

Re: [PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[Luis Claudio R. Goncalves]

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---

Re: [PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[Swaraj Gaikwad]

I agree that we can simplify this. I think !preemptible() would be
the most descriptive choice here, as it directly expresses the
constraint, we cannot take a sleeping lock when preemption is
disabled.
The updated check would be:
    if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible())

I'll send a v2 with this change unless there are objections.

Swaraj

Re: [PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[Hao Li]

On Fri, Dec 19, 2025 at 10:29:11AM -0300, Luis Claudio R. Goncalves wrote:
> 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()?

Hi,

I might be misunderstanding the situation, but my current understanding
is as follows:

__might_sleep will report this BUG if it is called with IRQs disabled or
in atomic context. Therefore, to avoid this BUG, it seems necessary to
check preemptible(), since in_atomic() alone does not appear to be
sufficient.

As a side note, once Vlastimil's "sheaves for all" branch is merged into
mainline, the local_lock_cpu_slab(s, flags); statement that currently
triggers the BUG is expected to be removed. Furthermore, the entire
nolock path in SLUB is planned to be implemented using trylock
semantics, which should eliminate the possibility of sleeping, even on
RT kernels. At that point, it seems we would only need to guard against
deadlock risks from NMI and IRQ, so this condition might need to be
reverted to in_nmi() || in_hardirq() again.

Please let me know if I'm missing something here or if there are
additional constraints I haven't considered. I'd appreciate any
corrections or further insights.

Thanks

> 
> 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---
> 
> 

Re: [PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[Luis Claudio R. Goncalves]

On Fri, Dec 19, 2025 at 11:22:02PM +0800, Hao Li wrote:
> On Fri, Dec 19, 2025 at 10:29:11AM -0300, Luis Claudio R. Goncalves wrote:
> > 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()?
> 
> Hi,
> 
> I might be misunderstanding the situation, but my current understanding
> is as follows:
> 
> __might_sleep will report this BUG if it is called with IRQs disabled or
> in atomic context. Therefore, to avoid this BUG, it seems necessary to
> check preemptible(), since in_atomic() alone does not appear to be
> sufficient.

You are correct. I focused in the condition proposed (for which
preempt_count() was enough) and missed the real requirement.
 
> As a side note, once Vlastimil's "sheaves for all" branch is merged into
> mainline, the local_lock_cpu_slab(s, flags); statement that currently
> triggers the BUG is expected to be removed. Furthermore, the entire
> nolock path in SLUB is planned to be implemented using trylock
> semantics, which should eliminate the possibility of sleeping, even on
> RT kernels. At that point, it seems we would only need to guard against
> deadlock risks from NMI and IRQ, so this condition might need to be
> reverted to in_nmi() || in_hardirq() again.
> 
> Please let me know if I'm missing something here or if there are
> additional constraints I haven't considered. I'd appreciate any
> corrections or further insights.
> 
> Thanks
> 
> > 
> > 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---
> > 
> > 
> 
---end quoted text---

Re: [PATCH] slab: fix kmalloc_nolock() context check for PREEMPT_RT

[Vlastimil Babka]

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

As a side-note, I'm puzzled why that report says it's bisected to commit
0db4941d9dae ("bpf: Use rcu_read_lock_dont_migrate in bpf_sk_storage.c")

I'll reply to the original report though.

> 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() ))
> +		/*
> +		 * 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
>