On Thu, Jul 17, 2025 at 8:12 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Thu, 17 Jul 2025 07:57:27 -0700 > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > I still don't understand what problem is being solved. > > As current tracepoint code stands there is no issue with it at all > > on PREEMPT_RT from bpf pov. > > bpf progs that attach to tracepoints are not sleepable. > > They don't call rt_spinlock either. > > Recognizing tracepoints that can sleep/fault and allow > > sleepable bpf progs there is on our to do list, > > but afaik it doesn't need any changes to tracepoint infra. > > There is no need to replace existing preempt_disable wrappers > > with sleepable srcu_fast or anything else. > > From the PREEMPT_RT point of view, it wants BPF to be preemptable. It > may stop migration, but if someone adds a long running BPF program > (when I say long running, it could be anything more than 10us), and it > executes on a low priority task. If that BPF program is not preemptable > it can delay a high priority task from running. That defeats the > purpose of PREEMPT_RT. > > If this is unsolvable, then we will need to make PREEMPT_RT and BPF > mutually exclusive in the configs. Stop this fud, please. bpf progs were preemptible for years and had no issue in RT. tracepoints are using preempt_disable() still and that's a tracepoint infra problem. Nothing to do with users of tracepoints.
