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

[Thomas Gleixner]

Andy Lutomirski <luto@xxxxxxxxxx> writes:

> On Tue, May 5, 2020 at 7:13 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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?

Yes. Before RCU is reestablished and after. I'll rephrase.