Re: [BUG] possible deadlock in __schedule (with reproducer available)

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Nov 25, 2024 at 05:24:05AM +0000, Ruan Bonan wrote:

> From the discussion, it appears that the root cause might involve
> specific printk or BPF operations in the given context. To clarify and
> possibly avoid similar issues in the future, are there guidelines or
> best practices for writing BPF programs/hooks that interact with
> tracepoints, especially those related to scheduler events, to prevent
> such deadlocks?

The general guideline and recommendation for all tracepoints is to be
wait-free. Typically all tracer code should be.

Now, BPF (users) (ab)uses tracepoints to do all sorts and takes certain
liberties with them, but it is very much at the discretion of the BPF
user.

Slightly relaxed guideline would perhaps be to consider the context of
the tracepoint, notably one of: NMI, IRQ, SoftIRQ or Task context -- and
to not exceed the bounds of the given context.

More specifically, when the tracepoint is inside critical sections of
any sort (as is the case here) then it very much is on the BPF user to
not cause inversions.

At this point there really is no substitute for knowing what you're
doing. Knowledge is key.

In short; tracepoints should be wait-free, if you know what you're doing
you can perhaps get away with a little more.