Re: uprobe splat in PREEMP_RT

[Oleg Nesterov <oleg@redhat.com>]

On 04/02, Oleg Nesterov wrote:
>
> 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.

IOW.

I understand that seqcount_t is not RT-friendly, but why exactly do
you think the patch above can make the things worse?

Oleg.