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

[Sebastian Andrzej Siewior]

On 2026-06-01 10:40:45 [+0200], Peter Zijlstra wrote:
> > 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.

This does not happen. It only happens if the associated lock is
preemptible. This is not the case for uprobes.c so there is no lock/
unlock.

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

So it would work if there is no lock associated or it is something like
raw_spinlock_t.

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

Do I make sense or do I miss something obvious? On the other it would
make sense to have this even for spinlock_t assuming the try_begin
version does not try spin and expect to make progress (which it does not
for the current users).

Sebastian