lkml.org 
[lkml]   [2020]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch V4 part 1 22/36] tracing: Provide lockdep less trace_hardirqs_on/off() variants
Date
Andy Lutomirski <luto@kernel.org> writes:

> 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?

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

\
 
 \ /
  Last update: 2020-05-07 20:52    [W:0.177 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site