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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 16 Jun 2014 22:43:38 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Peter Zijlstra <peterz@...radead.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>,
	registosites@...mail.com, srivatsa@....edu
Subject: Re: [PATCH 11/15] x86: Rewrite cyc2ns to avoid the need to disable IRQs

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

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


We have asked him to do lots of tests as we initially though its
because of some cpufreq changes, but finally we came to the conclusion
that reverting below two commits fixes his issues over 3.14:

20d1c86 sched/clock, x86: Rewrite cyc2ns() to avoid the need to disable IRQs
57c67da sched/clock, x86: Move some cyc2ns() code around

(some more commits were reverted as well to revert these two cleanly,
but he still had issues after those reverts and only after reverting these two
his problem got fixed)..

He couldn't do a bisect as it was broken with compilation errors ..

Can you give any pointers, so that he can get it fixed ?

Thanks.

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