Re: uprobe splat in PREEMP_RT

[Oleg Nesterov <oleg@redhat.com>]

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.