On Thu, Jul 17, 2025 at 08:27:24AM -0700, Alexei Starovoitov wrote: > 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. And the tracepoint infrastructure is in fact where my proposed fix is located. To be fair, several upgrades to SRCU-fast were required to handle this particular use case. But to Steven's point, if there was no feasible fix, wherever that fix might be, then users of real-time Linux would (at best!) need to be *very* careful about how they used BPF. In fact, those having safety-critical appliations might well choose to turn BPF off entirely, just to prevent accidents. Thanx, Paul
