Re: [PATCH v2 01/20] locking/rt: Use raw_spin_lock_irqsave() in __rwbase_read_unlock()

From: Peter Zijlstra

Date: Mon Jun 01 2026 - 04:44:13 EST


On Sat, May 30, 2026 at 12:26:20PM +0200, Paolo Bonzini wrote:

> From f2c604a94cdea9bb96bb21c8a29288eae6cbac67 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Date: Sat, 30 May 2026 10:54:36 +0200
> Subject: [PATCH] seqcount: allow raw_seqcount_try_begin in atomic context
>
> When raw_seqcount_try_begin() is used, the typical action when
> the seqcount is busy is to take the same lock that the writer uses.
> Another possibility, found in kernel/events/uprobes.c, is to delay
> the work to a safe point using RCU. Either way there is no need
> to guarantee progress of the writer under CONFIG_PREEMPT_RT,
> because the caller is not going to call raw_seqcount_try_begin() in a loop.
>
> However, raw_seqcount_try_begin() currently uses seqprop_sequence()
> via raw_read_seqcount(), and therefore does a lock/unlock of the
> write-side lock on PREEMPT_RT kernel. This prevents it from being
> used in atomic context. Use __seqprop_sequence() instead of
> raw_read_seqcount() to allow it.
>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Sean Christopherson <seanjc@xxxxxxxxxx>
> Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> ---
> include/linux/seqlock.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
> index 5a40252b8334..9adbf5d9667c 100644
> --- a/include/linux/seqlock.h
> +++ b/include/linux/seqlock.h
> @@ -338,7 +338,10 @@ SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex)
> */
> #define raw_seqcount_try_begin(s, start) \
> ({ \
> - start = raw_read_seqcount(s); \
> + start = __seqprop_sequence(s); \
> + \
> + if (!(start & 1)) \
> + kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX); \
> !(start & 1); \
> })

Yeah, I think this makes sense. Thanks!