Re: uprobe splat in PREEMP_RT

[Oleg Nesterov <oleg@redhat.com>]

OK, it seems we can't understand each other. Probably my fault.

So, it think that

	static inline bool __seqprop_preemptible(const seqcount_t *s)
	{
		return false;
	}

should return true. Well because it is preemptible just like
SEQCOUNT_LOCKNAME(mutex) or, if PREEMPT_RT=y, SEQCOUNT_LOCKNAME(spinlock).

Am I wrong?

Oleg.

On 04/02, Oleg Nesterov wrote:
>
> On 04/02, Sebastian Sewior wrote:
> >
> > On 2025-04-02 14:12:28 [+0200], Oleg Nesterov wrote:
> > > On 04/02, Sebastian Sewior wrote:
> > > >
> > > > On 2025-04-02 13:31:43 [+0200], Oleg Nesterov wrote:
> > > > >
> > > > > IOW.
> > > > >
> > > > > I understand that seqcount_t is not RT-friendly, but why exactly do
> > > > > you think the patch above can make the things worse?
> > > >
> > > > We wouldn't notice such a case.
> > >
> > > Sebastian, could you spell please?
> > >
> > > What case we wouldn't notice?
> >
> > I'm sorry. It wouldn't notice that preemption isn't disabled and yell.
> >
> > > With this patch write_seqcount_begin(seqcount_t) will notice that
> > > seqprop_preemptible() is true and do preempt_disable() itself.
> >
> > Yes, but that we don't want. This would disable preemption for the whole
> > section and not allow anything on PREEMPT_RT what would be possible
> > otherwise. Like acquire a spinlock_t or so.
>
> Still can't understand...
>
> Currently __seqprop_assert() does lockdep_assert_preemption_disabled().
> This means that at least with PREEMPT_RT=y preemption must be disabled
> even before write_seqcount_begin(seqcount_t).
>
> That is why (I guess) for example i_size_write() does
> preempt_disable() before write_seqcount_begin(&inode->i_size_seqcount).
>
> > Yes, none of this would affect hprobe_expire().
>
> Yes.
>
> Oleg.