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

Message-ID: <5384F410.6000604@codeaurora.org>
Date:	Tue, 27 May 2014 13:22:40 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Corey Minyard <cminyard@...sta.com>,
	linux-rt-users@...r.kernel.org, minyard@....org,
	Stanislav Meduna <stano@...una.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm: Set hardirq tracing to on when idling

On 05/27/14 12:39, Arnd Bergmann wrote:
> On Tuesday 27 May 2014 12:33:38 Stephen Boyd wrote:
>> On 05/27/14 12:27, 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.
>> stop_critical_timings() is called in the generic idle loop. It looks
>> like stop_critical_timings() just isn't written correctly. All it does
>> is turn off the tracer, but it doesn't prevent future calls to
>> spinlocks, etc. from causing the tracer to turn on again between calls
>> to stop/start_critical_timings(). It seems better to prevent any more
>> tracing from happening between a call to stop_critical_timings() and
>> start_critical_timings() so we don't have to litter calls to that
>> function throughout the idle path.
> But are there any such calls in the idle function? I understand what
> you are doing in your patch, but I don't see why you have to actually
> do it.
>

Yes in my build it happens immediately after in rcu_enter_idle(). It
would also happen if you had a cpuidle driver that notified the core
that the timers stop during idle (FEAT_C3_STOP). In that case we would
call clockevents_notify() which will call raw_spin_lock_irqsave().

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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