linux-kernel - Re: x86 PMU broken in current Linus' tree

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, 8 Aug 2016 12:26:15 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	Mike Galbraith <umgwanakikbuti@...il.com>
Subject: Re: x86 PMU broken in current Linus' tree

On Tue, Aug 02, 2016 at 02:55:24PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 02, 2016 at 02:04:58PM +0200, Jiri Kosina wrote:
> > With current Linus' tree (HEAD == 731c7d3a20), I am getting bogus MSR 
> > write warning during bootup, and kernel panic when shutting PMUs down 
> > during poweroff.
> > 
> > The MSR warning is below, the camera capture of the poweroff panic can be 
> > found at
> > 
> > 	http://www.jikos.cz/jikos/junk/pmu-panic.jpg
> > 
> > The last previous kernel version that I've booted on this particular 
> > machine was 4.7.0-rc4, and it had neither of those symptoms, so I can 
> > eventually bisect if needed.
> > 
> > === [ snip ] ==
> > [    0.136000] smpboot: CPU0: Intel(R) Core(TM)2 Duo CPU     L9400  @ 1.86GHz (family: 0x6, model: 0x17, stepping: 0x6)
> > [    0.136000] Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
> > [    0.136000] ... version:                2
> > [    0.136000] ... bit width:              40
> > [    0.136000] ... generic registers:      2
> > [    0.136000] ... value mask:             000000ffffffffff
> > [    0.136000] ... max period:             000000007fffffff
> > [    0.136000] ... fixed-purpose events:   3
> > [    0.136000] ... event mask:             0000000700000003
> > [    0.136000] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
> > [    0.136000] unchecked MSR access error: WRMSR to 0xdf (tried to write 0x000000ff80000001) at rIP: 0xffffffff90004acc (x86_perf_event_set_period+0xdc/0x190)
> 
> 'Curious'.. :/
> 
> x86_perf_event_set_period() only does:
> 
>   wrmsrl(hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);
> 
> and hwc->event ends up being:
> 
>   MSR_ARCH_PERFMON_PERFCTR0 + index
> 
> From which we can deduce that index = 0xdf - 0xc1 = 30, which is
> somewhat larger than the max reported number of counters (2).
> 
> Lemme go see how that can happen.

So I can reproduce on my Lenovo T500 which has a Core2 as well. By long
and tedious printk() it looks like the event constraint:

  FIXED_EVENT_CONSTRAINT(0x003c, 1), /* CPU_CLK_UNHALTED.CORE */

which is updated in:

  intel_pmu_init()

to include the generic counter masks, gets corrupted for some reason.
But the moment I put printk()s in there to print the idxmsk64 values,
everything works as expected again.

I'll go prod mode.