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

[Peter Zijlstra]

On Mon, Jun 01, 2026 at 01:11:09PM +0200, Sebastian Andrzej Siewior wrote:
> 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).

Ah, so I was thinking that since it is try_begin(), it is already set up
for failure and we could elide that initial lock+unlock thing. But yes,
I suppose the user could simply use &s->seqcount to get the seqcount_t
variant.

Let me forget I ever seen this patch ;-)