Re: [PATCH v9 5/7] tracing: Centralize preemptirq tracepoints and unify their usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 11 Jul 2018 09:19:44 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Wed, 11 Jul 2018 15:12:56 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
> > On Thu, Jun 28, 2018 at 11:21:47AM -0700, Joel Fernandes wrote:  
> > > One note, I have to check for lockdep recursion in the code that calls
> > > the trace events API and bail out if we're in lockdep recursion    
> > 
> > I'm not seeing any new lockdep_recursion checks...  
> 
> I believe he's talking about this part:
> 
> +void trace_hardirqs_on(void)
> +{
> +	if (lockdep_recursing(current) || !this_cpu_read(tracing_irq_cpu))
> +		return;
> +

And the reason he said this is new, IIUC, is because the old way we
could still do irqsoff tracing even if lockdep_recursion is set. Now,
irqsoff tracing is disable within lockdep_recursion.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux