linux-kernel - Re: [PATCH] tracing/irqtrace: only call trace_hardirqs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180501153840.7281022a@gandalf.local.home>
Date:   Tue, 1 May 2018 15:38:40 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Nicholas Piggin <npiggin@...il.com>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when
 state changes

On Tue, 1 May 2018 21:19:51 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Tue, May 01, 2018 at 02:46:20PM -0400, Steven Rostedt wrote:
> > On Fri, 17 Nov 2017 02:15:06 +1000
> > Nicholas Piggin <npiggin@...il.com> wrote:
> >   
> > > In local_irq_save and local_irq_restore, only call irq tracing when
> > > the flag state acutally changes. It is not unexpected for the state
> > > to go disable->disable.
> > > 
> > > This allows the irq tracing code to better track superfluous
> > > enables and disables, and in future could issue warnings. For the
> > > most part they are harmless, but they can indicate that the caller
> > > has lost track of its irq state.  
> > 
> > I missed this before (that was a busy time, I missed a lot of emails
> > then :-/ ). 
> > 
> > Anyway, this makes sense.
> > 
> > Peter?  
> 
> I'm confused. The patch calls the trace hooks less often, so how can it
> then better track superfluous calls?
> 
> > > @@ -110,7 +110,8 @@ do {						\
> > >  #define local_irq_save(flags)				\
> > >  	do {						\
> > >  		raw_local_irq_save(flags);		\
> > > -		trace_hardirqs_off();			\
> > > +		if (!raw_irqs_disabled_flags(flags))	\
> > > +			trace_hardirqs_off();		\
> > >  	} while (0)  
> 
> Here we only call the trace hook when we actually did an ON->OFF change
> and loose the call on OFF->OFF.
> 
> > > @@ -118,9 +119,11 @@ do {						\
> > >  	do {						\
> > >  		if (raw_irqs_disabled_flags(flags)) {	\
> > >  			raw_local_irq_restore(flags);	\
> > > -			trace_hardirqs_off();		\
> > > +			if (!irqs_disabled())		\
> > > +				trace_hardirqs_off();	\  
> 
> Only call on ON->OFF, ignore OFF->OFF.
> 
> > >  		} else {				\
> > > -			trace_hardirqs_on();		\
> > > +			if (irqs_disabled())		\
> > > +				trace_hardirqs_on();	\
> > >  			raw_local_irq_restore(flags);	\
> > >  		}					\
> > >  	} while (0)  
> 
> Only call on OFF->ON, ignore ON->ON.
> 
> 
> Now, lockdep only minimally tracks these otherwise redundant operations;
> see redundant_hardirqs_{on,off} counters, and loosing that doesn't seen
> like a big issue.
> 
> But I'm confused how this helps track superfluous things, it looks like
> it explicitly tracks _less_ superfluous transitions.

I think it is about triggering on OFF->OFF a warning, as that would
only happen if we have:

	local_irq_save(flags);
	[..]
	local_irq_disable();

-- Steve