Re: [patch V4 part 1 22/36] tracing: Provide lockdep less trace_hardirqs_on/off() variants

2020-05-07 Thread Thomas Gleixner
Andy Lutomirski writes: > On Tue, May 5, 2020 at 7:13 AM Thomas Gleixner wrote: >> >> trace_hardirqs_on/off() is only partially safe vs. RCU idle. The tracer >> core itself is safe, but the resulting tracepoints can be utilized by >> e.g. BPF which is unsafe. >> >> Provide variants which do not

Re: [patch V4 part 1 22/36] tracing: Provide lockdep less trace_hardirqs_on/off() variants

2020-05-07 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:13 AM Thomas Gleixner wrote: > > trace_hardirqs_on/off() is only partially safe vs. RCU idle. The tracer > core itself is safe, but the resulting tracepoints can be utilized by > e.g. BPF which is unsafe. > > Provide variants which do not contain the lockdep invocation so

[patch V4 part 1 22/36] tracing: Provide lockdep less trace_hardirqs_on/off() variants

2020-05-05 Thread Thomas Gleixner
trace_hardirqs_on/off() is only partially safe vs. RCU idle. The tracer core itself is safe, but the resulting tracepoints can be utilized by e.g. BPF which is unsafe. Provide variants which do not contain the lockdep invocation so the lockdep and tracer invocations can be split at the call site