Re: uprobe splat in PREEMP_RT

Oleg Nesterov
2025-04-02T11:20:54Z

On 04/02, Sebastian Sewior wrote:
>
> On 2025-04-02 11:10:45 [+0200], Oleg Nesterov wrote:
> > Add Peter.
> >
> > I never understood why __seqprop_preemptible() returns false.
> > Stupid question, perhaps
> >
> > --- x/include/linux/seqlock.h
> > +++ x/include/linux/seqlock.h
> > @@ -213,12 +213,11 @@ static inline unsigned __seqprop_sequenc
> >
> > static inline bool __seqprop_preemptible(const seqcount_t *s)
> > {
> > - return false;
> > + return true;
> > }
> >
> > static inline void __seqprop_assert(const seqcount_t *s)
> > {
> > - lockdep_assert_preemption_disabled();
> > }
> >
> > #define __SEQ_RT IS_ENABLED(CONFIG_PREEMPT_RT)
> >
> > makes more sense?
> >
> > Then we can remove the no longer necessary preempt_disable()'s
> > before write_seqcount_begin() in other users of seqcount_t.
>
> This depends on locktype that is coupled with the seqcount.

Yes.

But seqcount_t doesn't have the "internal" lock. Unlike other
seqcount's defined by SEQCOUNT_LOCKNAME().

> If the lock disables preemption and relies on it then it must be somehow
> enforced on PREEMPT_RT or rely on the lock+unlock mechnanism to avoid
> deadlocks. Also it needs to be ensured that you don't have two writer
> since preemption is allowed.

Sorry, I don't understand.

Again, seqcount_t differs, it can't do lock+unlock like (say)
seqcount_spinlock_t.

Oleg.