[PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Gabriele Monaco]

raw_res_spin_unlock_irqrestore() calls raw_res_spin_unlock() and then
restores interrupts, this means preemption is enabled when interrupts
are still disabled (as part of raw_res_spin_unlock()) so this cannot
trigger an actual preemption.
This is inconsistent with other spinlock implementations
(raw_spin_unlock_irqrestore() and bpf_res_spin_unlock_irqrestore()
itself).

Adjust the macro to ensure interrupts are enabled before enabling
preemption, allowing to schedule at that point. Make the same
modification in the error path of raw_res_spin_lock_irqsave().

Fixes: 101acd2e78b1 ("rqspinlock: Add macros for rqspinlock usage")
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
 include/asm-generic/rqspinlock.h | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/rqspinlock.h b/include/asm-generic/rqspinlock.h
index 151d267a49..4d46643f46 100644
--- a/include/asm-generic/rqspinlock.h
+++ b/include/asm-generic/rqspinlock.h
@@ -243,12 +243,20 @@ static __always_inline void res_spin_unlock(rqspinlock_t *lock)
 	({                                        \
 		int __ret;                        \
 		local_irq_save(flags);            \
-		__ret = raw_res_spin_lock(lock);  \
-		if (__ret)                        \
+		preempt_disable();                \
+		__ret = res_spin_lock(lock);      \
+		if (__ret) {                      \
 			local_irq_restore(flags); \
+			preempt_enable();         \
+		}                                 \
 		__ret;                            \
 	})
 
-#define raw_res_spin_unlock_irqrestore(lock, flags) ({ raw_res_spin_unlock(lock); local_irq_restore(flags); })
+#define raw_res_spin_unlock_irqrestore(lock, flags) \
+	({                                          \
+		res_spin_unlock(lock);              \
+		local_irq_restore(flags);           \
+		preempt_enable();                   \
+	})
 
 #endif /* __ASM_GENERIC_RQSPINLOCK_H */

base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
-- 
2.54.0

Re: [PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Arnd Bergmann]

On Tue, Jun 9, 2026, at 11:49, Gabriele Monaco wrote:
> raw_res_spin_unlock_irqrestore() calls raw_res_spin_unlock() and then
> restores interrupts, this means preemption is enabled when interrupts
> are still disabled (as part of raw_res_spin_unlock()) so this cannot
> trigger an actual preemption.
> This is inconsistent with other spinlock implementations
> (raw_spin_unlock_irqrestore() and bpf_res_spin_unlock_irqrestore()
> itself).
>
> Adjust the macro to ensure interrupts are enabled before enabling
> preemption, allowing to schedule at that point. Make the same
> modification in the error path of raw_res_spin_lock_irqsave().
>
> Fixes: 101acd2e78b1 ("rqspinlock: Add macros for rqspinlock usage")

Should this be Cc:stable@vger.kernel.org to get backported?

Did you see this cause measurable performance problems,
or did you find it through inspection?

> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>

Acked-by: Arnd Bergmann <arnd@arndb.de> # asm-generic

This should probably get merged through the BPF tree, but I've
added the kernel/locking maintainers to Cc as well, since I
feel it's more useful to have them look at it than me.

Maybe it would be good to update (as a separate patch) the
MAINTAINERS file so the locking subsystem also includes the
headers currently missing:

arch/*/include/asm/*spinlock*.h
arch/*/include/asm/*rwlock*.h
include/asm-generic/*spinlock*.h
include/asm-generic/*rwlock*.h

       Arnd

(full patch quoted below)

> ---
>  include/asm-generic/rqspinlock.h | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-generic/rqspinlock.h 
> b/include/asm-generic/rqspinlock.h
> index 151d267a49..4d46643f46 100644
> --- a/include/asm-generic/rqspinlock.h
> +++ b/include/asm-generic/rqspinlock.h
> @@ -243,12 +243,20 @@ static __always_inline void 
> res_spin_unlock(rqspinlock_t *lock)
>  	({                                        \
>  		int __ret;                        \
>  		local_irq_save(flags);            \
> -		__ret = raw_res_spin_lock(lock);  \
> -		if (__ret)                        \
> +		preempt_disable();                \
> +		__ret = res_spin_lock(lock);      \
> +		if (__ret) {                      \
>  			local_irq_restore(flags); \
> +			preempt_enable();         \
> +		}                                 \
>  		__ret;                            \
>  	})
> 
> -#define raw_res_spin_unlock_irqrestore(lock, flags) ({ 
> raw_res_spin_unlock(lock); local_irq_restore(flags); })
> +#define raw_res_spin_unlock_irqrestore(lock, flags) \
> +	({                                          \
> +		res_spin_unlock(lock);              \
> +		local_irq_restore(flags);           \
> +		preempt_enable();                   \
> +	})
> 
>  #endif /* __ASM_GENERIC_RQSPINLOCK_H */
>
> base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
> -- 
> 2.54.0

Re: [PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Gabriele Monaco]

On Tue, 2026-06-09 at 13:22 +0200, Arnd Bergmann wrote:
> Should this be Cc:stable@vger.kernel.org to get backported?

Not sure if the Fixes: is enough to trigger the automation, I rarely
remember to Cc:stable@vger.kernel.org and they're usually picked.

In case I guess I'd need to re-submit the patch right?

> Did you see this cause measurable performance problems,
> or did you find it through inspection?

I noticed it while debugging an ENOMEM issue in the test_maps BPF
selftest on PREEMPT_RT and this was an obvious cuplrit (irq_work not
scheduled during a stress run). Turns out the problem is still there
after this fix though.

> 
> > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de> # asm-generic

Thanks,
Gabriele

> 
> This should probably get merged through the BPF tree, but I've
> added the kernel/locking maintainers to Cc as well, since I
> feel it's more useful to have them look at it than me.
> 
> Maybe it would be good to update (as a separate patch) the
> MAINTAINERS file so the locking subsystem also includes the
> headers currently missing:
> 
> arch/*/include/asm/*spinlock*.h
> arch/*/include/asm/*rwlock*.h
> include/asm-generic/*spinlock*.h
> include/asm-generic/*rwlock*.h
> 
>        Arnd
> 
> (full patch quoted below)
> 
> > ---
> >  include/asm-generic/rqspinlock.h | 14 +++++++++++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/asm-generic/rqspinlock.h 
> > b/include/asm-generic/rqspinlock.h
> > index 151d267a49..4d46643f46 100644
> > --- a/include/asm-generic/rqspinlock.h
> > +++ b/include/asm-generic/rqspinlock.h
> > @@ -243,12 +243,20 @@ static __always_inline void 
> > res_spin_unlock(rqspinlock_t *lock)
> >  	({                                        \
> >  		int __ret;                        \
> >  		local_irq_save(flags);            \
> > -		__ret = raw_res_spin_lock(lock);  \
> > -		if (__ret)                        \
> > +		preempt_disable();                \
> > +		__ret = res_spin_lock(lock);      \
> > +		if (__ret) {                      \
> >  			local_irq_restore(flags); \
> > +			preempt_enable();         \
> > +		}                                 \
> >  		__ret;                            \
> >  	})
> > 
> > -#define raw_res_spin_unlock_irqrestore(lock, flags) ({ 
> > raw_res_spin_unlock(lock); local_irq_restore(flags); })
> > +#define raw_res_spin_unlock_irqrestore(lock, flags) \
> > +	({                                          \
> > +		res_spin_unlock(lock);              \
> > +		local_irq_restore(flags);           \
> > +		preempt_enable();                   \
> > +	})
> > 
> >  #endif /* __ASM_GENERIC_RQSPINLOCK_H */
> > 
> > base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
> > -- 
> > 2.54.0

Re: [PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Arnd Bergmann]

On Tue, Jun 9, 2026, at 15:04, Gabriele Monaco wrote:
> On Tue, 2026-06-09 at 13:22 +0200, Arnd Bergmann wrote:
>> Should this be Cc:stable@vger.kernel.org to get backported?
>
> Not sure if the Fixes: is enough to trigger the automation, I rarely
> remember to Cc:stable@vger.kernel.org and they're usually picked.

There is always human interaction. If you just have 'Fixes',
this means someone will have to look at the patch carefully
and make a decision, since a lot of bugfix patches either don't
apply to old kernels or don't fall under the rules for stable
backports.

If the patch gets tagged Cc:, this means it is expected to be
backported and needs less manual work.

> In case I guess I'd need to re-submit the patch right?

It can be added by whoever picks up the patch.

>> Did you see this cause measurable performance problems,
>> or did you find it through inspection?
>
> I noticed it while debugging an ENOMEM issue in the test_maps BPF
> selftest on PREEMPT_RT and this was an obvious cuplrit (irq_work not
> scheduled during a stress run). Turns out the problem is still there
> after this fix though.

Ok

       Arnd

Re: [PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Peter Zijlstra]

On Tue, Jun 09, 2026 at 01:22:35PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 9, 2026, at 11:49, Gabriele Monaco wrote:
> > raw_res_spin_unlock_irqrestore() calls raw_res_spin_unlock() and then
> > restores interrupts, this means preemption is enabled when interrupts
> > are still disabled (as part of raw_res_spin_unlock()) so this cannot
> > trigger an actual preemption.
> > This is inconsistent with other spinlock implementations
> > (raw_spin_unlock_irqrestore() and bpf_res_spin_unlock_irqrestore()
> > itself).
> >
> > Adjust the macro to ensure interrupts are enabled before enabling
> > preemption, allowing to schedule at that point. Make the same
> > modification in the error path of raw_res_spin_lock_irqsave().
> >
> > Fixes: 101acd2e78b1 ("rqspinlock: Add macros for rqspinlock usage")

Yeah, this is right. spinlocks always get one preempt_disable, in
addition they might also get irq or bh disable.

Re: [PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Kumar Kartikeya Dwivedi]

On Tue Jun 9, 2026 at 3:04 PM CEST, Gabriele Monaco wrote:
> On Tue, 2026-06-09 at 13:22 +0200, Arnd Bergmann wrote:
>> Should this be Cc:stable@vger.kernel.org to get backported?
>
> Not sure if the Fixes: is enough to trigger the automation, I rarely
> remember to Cc:stable@vger.kernel.org and they're usually picked.
>
> In case I guess I'd need to re-submit the patch right?
>
>> Did you see this cause measurable performance problems,
>> or did you find it through inspection?
>
> I noticed it while debugging an ENOMEM issue in the test_maps BPF
> selftest on PREEMPT_RT and this was an obvious cuplrit (irq_work not
> scheduled during a stress run). Turns out the problem is still there
> after this fix though.

I would imagine this to be the least of your problems, I think there's a bunch
of blockers for complete selftests passing with PREEMPT_RT support in BPF.

>
>>
>> > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
>>
>> Acked-by: Arnd Bergmann <arnd@arndb.de> # asm-generic

The patch makes sense to me as well.

Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

Re: [PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Gabriele Monaco]

On Tue, 2026-06-09 at 16:42 +0200, Kumar Kartikeya Dwivedi wrote:
> On Tue Jun 9, 2026 at 3:04 PM CEST, Gabriele Monaco wrote:
> > On Tue, 2026-06-09 at 13:22 +0200, Arnd Bergmann wrote:
> > 
> > > Did you see this cause measurable performance problems,
> > > or did you find it through inspection?
> > 
> > I noticed it while debugging an ENOMEM issue in the test_maps BPF
> > selftest on PREEMPT_RT and this was an obvious cuplrit (irq_work
> > not scheduled during a stress run). Turns out the problem is still
> > there after this fix though.
> 
> I would imagine this to be the least of your problems, I think
> there's a bunch of blockers for complete selftests passing with
> PREEMPT_RT support in BPF.
> 

Well, I'm starting to believe that too..
At the moment on well tuned machines we are only observing ENOMEM
issues in the test_maps and only when it's literally hogging the
allocator (preallocation is off and 100 treads do updates in parallel).

What else are you expecting to fail under PREEMPT_RT?

> > > > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> > > 
> > > Acked-by: Arnd Bergmann <arnd@arndb.de> # asm-generic
> 
> The patch makes sense to me as well.
> 
> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

Thanks,
Gabriele

Re: [PATCH] rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule

[Alexei Starovoitov]

On Tue Jun 9, 2026 at 6:04 AM PDT, Gabriele Monaco wrote:
> On Tue, 2026-06-09 at 13:22 +0200, Arnd Bergmann wrote:
>> Should this be Cc:stable@vger.kernel.org to get backported?
>
> Not sure if the Fixes: is enough to trigger the automation, I rarely
> remember to Cc:stable@vger.kernel.org and they're usually picked.
>
> In case I guess I'd need to re-submit the patch right?

Yes. For whatever reason the patch didn't reach the patchwork.

Please resubmit with [PATCH bpf-next] subject, so that CI can test it properly.
And collect Acks.