linux-kernel - Re: [PATCH] arm: Set hardirq tracing to on when idling

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] [day] [month] [year] [list]

Message-ID: <4260533.1h2PQ8Ph4h@wuerfel>
Date:	Wed, 28 May 2014 08:46:43 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org, minyard@....org
Cc:	Corey Minyard <cminyard@...sta.com>,
	Stanislav Meduna <stano@...una.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm: Set hardirq tracing to on when idling

On Tuesday 27 May 2014 19:28:06 Corey Minyard wrote:
> On 05/27/2014 02:27 PM, Arnd Bergmann wrote:
> > On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
> >> On 05/27/14 11:49, Arnd Bergmann wrote:
> >>> You also commented in that thread about stop_critical_timings()/
> >>> start_critical_timings(). Corey, can you look at that, too? I
> >>> think it's designed to avoid the issue you are seeing but
> >>> for some reason doesn't.
> >> I sent a patch last week to "solve" this problem. I'm not sure if it's
> >> right but it works for me.
> >>
> >> https://lkml.org/lkml/2014/5/19/607
> > I think that one was also wrong, as the intention of the existing
> > stop_critical_timings() function is already to do the same that
> > Corey's patch does, i.e. stop the trace before we go to idle as
> > if we were turning IRQs on.
> >
> > Corey, does it work for you if you replace the new trace_hardirqs_on()
> > you added with time_hardirqs_on() or stop_critical_timing()?
> 
> Well, more information on this.  It turns out that the generic idle loop
> calls stop_critical_timing() and start_critical timing(), so the
> arch_cpu_idle() shouldn't have to.
> 
> However, the idle loop calls rcu_idle_enter() after it calls
> stop_critical_timing(), and that is resetting the critical timing, it
> appears.  It's disabling/enabling interrupts in rcu_idle_enter().  If I
> switch the order of the rcu_idle and critical timing calls, the issue
> goes away.
> 
> Stephen's patch does not seem to be necessary for my issue. I tried with
> the patch applied, too.  It doesn't seem to hurt, at least.  It did not
> fix the problem by itself, though.

Interesting, it looked like the "big hammer" solution to me (compared to
yours) that should deal with the problem in any case.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/