linux-stable.git/arch/x86/kernel, branch linux-4.5.y

perf/x86/intel/pt: Generate PMI in the STOP region as well

2016-06-01T19:16:56+00:00

commit ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c upstream.

Currently, the PT driver always sets the PMI bit one region (page) before
the STOP region so that we can wake up the consumer before we run out of
room in the buffer and have to disable the event. However, we also need
an interrupt in the last output region, so that we actually get to disable
the event (if no more room from new data is available at that point),
otherwise hardware just quietly refuses to start, but the event is
scheduled in and we end up losing trace data till the event gets removed.

For a cpu-wide event it is even worse since there may not be any
re-scheduling at all and no chance for the ring buffer code to notice
that its buffer is filled up and the event needs to be disabled (so that
the consumer can re-enable it when it finishes reading the data out). In
other words, all the trace data will be lost after the buffer gets filled
up.

This patch makes PT also generate a PMI when the last output region is
full.

Reported-by: Markus Metzger 
Signed-off-by: Alexander Shishkin 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/1462886313-13660-2-git-send-email-alexander.shishkin@linux.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

ACPI / processor: Request native thermal interrupt handling via _OSC

2016-05-11T09:21:40+00:00

commit a21211672c9a1d730a39aa65d4a5b3414700adfb upstream.

There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake-based systems by the Intel P-states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.

HWP interrupts use the thermal LVT which can be handled by Linux
natively, but on the affected Skylake-based systems SMM will respond
to it by default.  This is a problem for several reasons:
 - On the affected systems the SMM thermal LVT handler is broken (it
   will crash when invoked) and a BIOS update is necessary to fix it.
 - With thermal interrupt handled in SMM we lose all of the reporting
   features of the arch/x86/kernel/cpu/mcheck/therm_throt driver.
 - Some thermal drivers like x86-package-temp depend on the thermal
   threshold interrupts signaled via the thermal LVT.
 - The HWP interrupts are useful for debugging and tuning
   performance (if the kernel can handle them).
The native handling of thermal interrupts needs to be enabled
because of that.

This requires some way to tell SMM that the OS can handle thermal
interrupts.  That can be done by using _OSC/_PDC in processor
scope very early during ACPI initialization.

The meaning of _OSC/_PDC bit 12 in processor scope is whether or
not the OS supports native handling of interrupts for Collaborative
Processor Performance Control (CPPC) notifications.  Since on
HWP-capable systems CPPC is a firmware interface to HWP, setting
this bit effectively tells the firmware that the OS will handle
thermal interrupts natively going forward.

For details on _OSC/_PDC refer to:
http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html

To implement the _OSC/_PDC handshake as described, introduce a new
function, acpi_early_processor_osc(), that walks the ACPI
namespace looking for ACPI processor objects and invokes _OSC for
them with bit 12 in the capabilities buffer set and terminates the
namespace walk on the first success.

Also modify intel_thermal_interrupt() to clear HWP status bits in
the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents
them from firing continuously).

Signed-off-by: Srinivas Pandruvada 
[ rjw: Subject & changelog, function rename ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

x86/sysfb_efi: Fix valid BAR address range check

2016-05-11T09:21:36+00:00

commit c10fcb14c7afd6688c7b197a814358fecf244222 upstream.

The code for checking whether a BAR address range is valid will break
out of the loop when a start address of 0x0 is encountered.

This behaviour is wrong since by breaking out of the loop we may miss
the BAR that describes the EFI frame buffer in a later iteration.

Because of this bug I can't use video=efifb: boot parameter to get
efifb on my new ThinkPad E550 for my old linux system hard disk with
3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not
supporting the GPU.

This patch also add a trivial optimization to break out after we find
the frame buffer address range without testing later BARs.

Signed-off-by: Wang YanQing 
[ Rewrote changelog. ]
Signed-off-by: Matt Fleming 
Reviewed-by: Peter Jones 
Cc: Ard Biesheuvel 
Cc: David Herrmann 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tomi Valkeinen 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO

2016-05-11T09:21:36+00:00

commit 886123fb3a8656699dff40afa0573df359abeb18 upstream.

Currently we read the tsc radio: ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f;

Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the SDM
(35.5), the ratio bits are bit 8-15.

Ignoring the upper bits can result in an incorrect tsc ratio, which causes the
TSC calibration and the Local APIC timer frequency to be incorrect.

Fix this problem by masking 0xff instead.

[ tglx: Massaged changelog ]

Fixes: 7da7c1561366 "x86, tsc: Add static (MSR) TSC calibration on Intel Atom SoCs"
Signed-off-by: Chen Yu 
Cc: "Rafael J. Wysocki" 
Cc: Bin Gao 
Cc: Len Brown 
Link: http://lkml.kernel.org/r/1462505619-5516-1-git-send-email-yu.c.chen@intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/apic: Handle zero vector gracefully in clear_vector_irq()

2016-05-04T21:49:09+00:00

commit 1bdb8970392a68489b469c3a330a1adb5ef61beb upstream.

If x86_vector_alloc_irq() fails x86_vector_free_irqs() is invoked to cleanup
the already allocated vectors. This subsequently calls clear_vector_irq().

The failed irq has no vector assigned, which triggers the BUG_ON(!vector) in
clear_vector_irq().

We cannot suppress the call to x86_vector_free_irqs() for the failed
interrupt, because the other data related to this irq must be cleaned up as
well. So calling clear_vector_irq() with vector == 0 is legitimate.

Remove the BUG_ON and return if vector is zero,

[ tglx: Massaged changelog ]

Fixes: b5dc8e6c21e7 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors"
Signed-off-by: Keith Busch 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/mce: Avoid using object after free in genpool

2016-05-04T21:48:58+00:00

commit a3125494cff084b098c80bb36fbe2061ffed9d52 upstream.

When we loop over all queued machine check error records to pass them
to the registered notifiers we use llist_for_each_entry(). But the loop
calls gen_pool_free() for the entry in the body of the loop - and then
the iterator looks at node->next after the free.

Use llist_for_each_entry_safe() instead.

Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov 
Cc: Gong Chen 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/0205920@agluck-desk.sc.intel.com
Link: http://lkml.kernel.org/r/1459929916-12852-4-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf/x86/intel: Fix PEBS data source interpretation on Nehalem/Westmere

2016-04-12T14:33:49+00:00

commit e17dc65328057c00db7e1bfea249c8771a78b30b upstream.

Jiri reported some time ago that some entries in the PEBS data source table
in perf do not agree with the SDM. We investigated and the bits
changed for Sandy Bridge, but the SDM was not updated.

perf already implements the bits correctly for Sandy Bridge
and later. This patch patches it up for Nehalem and Westmere.

Signed-off-by: Andi Kleen 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: jolsa@kernel.org
Link: http://lkml.kernel.org/r/1456871124-15985-1-git-send-email-andi@firstfloor.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf/x86/intel: Use PAGE_SIZE for PEBS buffer size on Core2

2016-04-12T14:33:49+00:00

commit e72daf3f4d764c47fb71c9bdc7f9c54a503825b1 upstream.

Using PAGE_SIZE buffers makes the WRMSR to PERF_GLOBAL_CTRL in
intel_pmu_enable_all() mysteriously hang on Core2. As a workaround, we
don't do this.

The hard lockup is easily triggered by running 'perf test attr'
repeatedly. Most of the time it gets stuck on sample session with
small periods.

  # perf test attr -vv
  14: struct perf_event_attr setup                             :
  --- start ---
  ...
    'PERF_TEST_ATTR=/tmp/tmpuEKz3B /usr/bin/perf record -o /tmp/tmpuEKz3B/perf.data -c 123 kill >/dev/null 2>&1' ret 1

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Jiri Olsa 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Andi Kleen 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20160301190352.GA8355@krava.redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf/x86/intel: Fix PEBS warning by only restoring active PMU in pmi

2016-04-12T14:33:49+00:00

commit c3d266c8a9838cc141b69548bc3b1b18808ae8c4 upstream.

This patch tries to fix a PEBS warning found in my stress test. The
following perf command can easily trigger the pebs warning or spurious
NMI error on Skylake/Broadwell/Haswell platforms:

  sudo perf record -e 'cpu/umask=0x04,event=0xc4/pp,cycles,branches,ref-cycles,cache-misses,cache-references' --call-graph fp -b -c1000 -a

Also the NMI watchdog must be enabled.

For this case, the events number is larger than counter number. So
perf has to do multiplexing.

In perf_mux_hrtimer_handler, it does perf_pmu_disable(), schedule out
old events, rotate_ctx, schedule in new events and finally
perf_pmu_enable().

If the old events include precise event, the MSR_IA32_PEBS_ENABLE
should be cleared when perf_pmu_disable().  The MSR_IA32_PEBS_ENABLE
should keep 0 until the perf_pmu_enable() is called and the new event is
precise event.

However, there is a corner case which could restore PEBS_ENABLE to
stale value during the above period. In perf_pmu_disable(), GLOBAL_CTRL
will be set to 0 to stop overflow and followed PMI. But there may be
pending PMI from an earlier overflow, which cannot be stopped. So even
GLOBAL_CTRL is cleared, the kernel still be possible to get PMI. At
the end of the PMI handler, __intel_pmu_enable_all() will be called,
which will restore the stale values if old events haven't scheduled
out.

Once the stale pebs value is set, it's impossible to be corrected if
the new events are non-precise. Because the pebs_enabled will be set
to 0. x86_pmu.enable_all() will ignore the MSR_IA32_PEBS_ENABLE
setting. As a result, the following NMI with stale PEBS_ENABLE
trigger pebs warning.

The pending PMI after enabled=0 will become harmless if the NMI handler
does not change the state. This patch checks cpuc->enabled in pmi and
only restore the state when PMU is active.

Here is the dump:

  Call Trace:
     [] dump_stack+0x63/0x85
   [] warn_slowpath_common+0x82/0xc0
   [] warn_slowpath_null+0x1a/0x20
   [] intel_pmu_drain_pebs_nhm+0x2be/0x320
   [] intel_pmu_handle_irq+0x279/0x460
   [] ? native_write_msr_safe+0x6/0x40
   [] ? vunmap_page_range+0x20d/0x330
   [] ?  unmap_kernel_range_noflush+0x11/0x20
   [] ? ghes_copy_tofrom_phys+0x10f/0x2a0
   [] ? ghes_read_estatus+0x98/0x170
   [] perf_event_nmi_handler+0x2d/0x50
   [] nmi_handle+0x69/0x120
   [] default_do_nmi+0xe6/0x100
   [] do_nmi+0xe2/0x130
   [] end_repeat_nmi+0x1a/0x1e
   [] ? native_write_msr_safe+0x6/0x40
   [] ? native_write_msr_safe+0x6/0x40
   [] ? native_write_msr_safe+0x6/0x40
   <>    [] ?  x86_perf_event_set_period+0xd8/0x180
   [] x86_pmu_start+0x4c/0x100
   [] x86_pmu_enable+0x28d/0x300
   [] perf_pmu_enable.part.81+0x7/0x10
   [] perf_mux_hrtimer_handler+0x200/0x280
   [] ?  __perf_install_in_context+0xc0/0xc0
   [] __hrtimer_run_queues+0xfd/0x280
   [] hrtimer_interrupt+0xa8/0x190
   [] ?  __perf_read_group_add.part.61+0x1a0/0x1a0
   [] local_apic_timer_interrupt+0x38/0x60
   [] smp_apic_timer_interrupt+0x3d/0x50
   [] apic_timer_interrupt+0x8c/0xa0
     [] ?  __perf_read_group_add.part.61+0x1a0/0x1a0
   [] ?  smp_call_function_single+0xd5/0x130
   [] ?  smp_call_function_single+0xcb/0x130
   [] ?  __perf_read_group_add.part.61+0x1a0/0x1a0
   [] event_function_call+0x10a/0x120
   [] ? ctx_resched+0x90/0x90
   [] ? cpu_clock_event_read+0x30/0x30
   [] ? _perf_event_disable+0x60/0x60
   [] _perf_event_enable+0x5b/0x70
   [] perf_event_for_each_child+0x38/0xa0
   [] ? _perf_event_disable+0x60/0x60
   [] perf_ioctl+0x12d/0x3c0
   [] ? selinux_file_ioctl+0x95/0x1e0
   [] do_vfs_ioctl+0xa1/0x5a0
   [] ? sched_clock+0x9/0x10
   [] SyS_ioctl+0x79/0x90
   [] entry_SYSCALL_64_fastpath+0x1a/0xa4
  ---[ end trace aef202839fe9a71d ]---
  Uhhuh. NMI received for unknown reason 2d on CPU 2.
  Do you have a strange power saving mode enabled?

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Link: http://lkml.kernel.org/r/1457046448-6184-1-git-send-email-kan.liang@intel.com
[ Fixed various typos and other small details. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf/x86/intel/uncore: Remove SBOX support for BDX-DE

2016-04-12T14:33:49+00:00

commit 6cb2f1d9af5b0f0afdd4e689d969df4b5c76a4c2 upstream.

BDX-DE and BDX-EP share the same uncore code path. But there is no sbox
in BDX-DE. This patch remove SBOX support for BDX-DE.

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Tony Battersby 
Cc: Vince Weaver 
Link: http://lkml.kernel.org/r/37D7C6CF3E00A74B8858931C1DB2F0770589D336@SHSMSX103.ccr.corp.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman