Re: uprobe splat in PREEMP_RT

Sebastian Sewior
2025-04-02T12:22:01Z

On 2025-04-01 15:01:55 [-0700], Andrii Nakryiko wrote:
> 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()?

You don't have a lock associated with the seqcount. The writer side
ensure that there can only be one writer because the timer can only fire
once.
The reader side uses raw_seqcount_try_begin() so it does not require the
writer to make progress. Meaning if it preempts the writer then it will
continue and make progress.
If these conditions remain, why not
s/write_seqcount_begin/raw_write_seqcount_begin// ? This would avoid the
checks as per "I know best" and I don't have a reason why a lock would
make sense to exclude multiple writers.

> Peter, any opinion?

Sebastian