linux-kernel - Re: [PATCH 11/15] x86: Rewrite cyc2ns to avoid the need to disable IRQs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <BLU436-SMTP2374766AD1903C1E161D224C6110@phx.gbl>
Date:	Tue, 17 Jun 2014 13:47:53 +0100
From:	Mauro <registosites@...mail.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	Viresh Kumar <viresh.kumar@...aro.org>
CC:	Arjan van de Ven <arjan@...ux.intel.com>, lenb@...nel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Eliezer Tamir <eliezer.tamir@...ux.intel.com>,
	Zhang Rui <rui.zhang@...el.com>, jacob.jun.pan@...ux.intel.com,
	Mike Galbraith <bitbucket@...ine.de>,
	Ingo Molnar <mingo@...nel.org>, hpa@...or.com,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	Andy Lutomirski <luto@...capital.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	srivatsa@....edu
Subject: Re: [PATCH 11/15] x86: Rewrite cyc2ns to avoid the need to disable
 IRQs

On 17-06-2014 13:15, Peter Zijlstra wrote:
> On Mon, Jun 16, 2014 at 10:43:38PM +0530, Viresh Kumar wrote:
>> Cc'ing Mauro/Rafael/Srivatsa..
>>
>> On Thu, Dec 12, 2013 at 7:38 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>>> Use a ring-buffer like multi-version object structure which allows
>>> always having a coherent object; we use this to avoid having to
>>> disable IRQs while reading sched_clock() and avoids a problem when
>>> getting an NMI while changing the cyc2ns data.
>>>
>>>                         MAINLINE   PRE        POST
>>>
>>>     sched_clock_stable: 1          1          1
>>>     (cold) sched_clock: 329841     331312     257223
>>>     (cold) local_clock: 301773     310296     309889
>>>     (warm) sched_clock: 38375      38247      25280
>>>     (warm) local_clock: 100371     102713     85268
>>>     (warm) rdtsc:       27340      27289      24247
>>>     sched_clock_stable: 0          0          0
>>>     (cold) sched_clock: 382634     372706     301224
>>>     (cold) local_clock: 396890     399275     399870
>>>     (warm) sched_clock: 38194      38124      25630
>>>     (warm) local_clock: 143452     148698     129629
>>>     (warm) rdtsc:       27345      27365      24307
>>>
>>> Signed-off-by: Peter Zijlstra <peterz@...radead.org>
>>> ---
>>>  arch/x86/include/asm/timer.h     |   23 +++
>>>  arch/x86/kernel/cpu/perf_event.c |   14 +-
>>>  arch/x86/kernel/tsc.c            |  229 ++++++++++++++++++++++++++++++++++-----
>>>  3 files changed, 236 insertions(+), 30 deletions(-)
>>
>> Hi Peter,
>>
>> We have been following a bug around cpufreq changes in 3.14
>> (https://bugzilla.kernel.org/show_bug.cgi?id=77201) and our tests
>> narrowed it down to this patch after which things aren't working
>> as expected.
> 
>> Mauro (registosites@...mail.com) have reported that since 3.14
>> after doing hot-unplug/hotplug of CPU1, cpufreq POSTCHANGE notifications
>> for every second frequency change hangs his machine ..
> 
> Ah, just a freeze?

If you mean no output whatsoever and frozen to the point of needing a
hard shutdown/reboot, yes.

>> Last working tag was: 3.13.8 and it started failing from 3.14 and fails
>> for latest 3.15 as well..
>>
>> model name : AMD Turion(tm) 64 X2 Mobile Technology TL-64
>> CPUFreq driver: powernow-k8 ..
>> CPUs: Only two CPUs, sharing clock line
> 
> What's specific to this particular CPU?

That is a very good question, for which I don't have an answer, as far
as I know it is just like any other AMD mobile Turion X2 cpu.

>> Can you give any pointers, so that he can get it fixed ?
> 
> So what you can try is force a cyc2ns read before the write in
> set_cyc2ns_scale(). I think its possible that if we do not do the read,
> the write will wait for a 'free' slot indefinitely.

For that I'll need some help/pointers.


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)