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

Andy Lutomirski
2020-05-07T17:56:03Z

On Tue, May 5, 2020 at 7:13 AM Thomas Gleixner <tglx@linutronix.de> 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 the lockdep
> and tracer invocations can be split at the call site and placed properly.
>
> The new variants also do not use rcuidle as they are going to be called
> from entry code after/before context tracking.

I can't quite follow this. Are you saying that the new variants are
intended to be called by the entry code in a context where tracing is
acceptable and that the lockdep part will still be called in a context
where tracing is not acceptable?

--Andy