Re: uprobe splat in PREEMP_RT

Andrii Nakryiko
2025-04-01T22:02:08Z

On Tue, Apr 1, 2025 at 2:21 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 1 Apr 2025 14:04:22 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > Looks like write_seqcount_begin(&utask->ri_seqcount);
> > use in ri_timer() needs a fix ?
>

So, write_seqcount_begin()'s documentation states:

/**
* write_seqcount_begin() - start a seqcount_t write side critical section
* @s: Pointer to seqcount_t or any of the seqcount_LOCKNAME_t variants
*
* Context: sequence counter write side sections must be serialized and
* non-preemptible. Preemption will be automatically disabled if and
* only if the seqcount write serialization lock is associated, and
* preemptible. If readers can be invoked from hardirq or softirq
* context, interrupts or bottom halves must be respectively disabled.
*/

In our case we cannot have readers invoked from hardirq/softirq. It's
the writer that can be invoked from hardirq (timer).

So what did I do incorrectly here? Should I still disable hardirqs
just to satisfy that seqprop_assert()?

Peter, any opinion?

> Hmm,
>
> write_seqcount_begin(&utask->ri_seqcount);
>
> for_each_ret_instance_rcu(ri, utask->return_instances)
> hprobe_expire(&ri->hprobe, false);
>
> write_seqcount_end(&utask->ri_seqcount);
>
> How big can that loop be?
>
> Of course, we could just say not to use uprobes on PREEMPT_RT kernels?
> Otherwise, they could cause an unspecified latency.

There can't be more than 64 nested uretprobes, so it will be (in a
very-very unlikely event) at most 64 items. And that hprobe_expire()
operation is very fast. So I don't think latency is a big concert
here.

>
> -- Steve