talos-op-linux/arch/x86/kernel, branch v4.6-rc4

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2016-04-15T02:53:46+00:00

Pull x86 fixes from Ingo Molnar: "Misc fixes: a binutils fix, an lguest fix, an mcelog fix and a missing documentation fix" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mce: Avoid using object after free in genpool lguest, x86/entry/32: Fix handling of guest syscalls using interrupt gates x86/build: Build compressed x86 kernels as PIE x86/mm/pkeys: Add missing Documentation

Revert "x86: remove the kernel code/data/bss resources from /proc/iomem"

2016-04-14T19:55:32+00:00

This reverts commit c4004b02f8e5b9ce357a0bb1641756cc86962664. Sadly, my hope that nobody would actually use the special kernel entries in /proc/iomem were dashed by kexec. Which reads /proc/iomem explicitly to find the kernel base address. Nasty. Anyway, that means we can't do the sane and simple thing and just remove the entries, and we'll instead have to mask them out based on permissions. Reported-by: Zhengyu Zhang Reported-by: Dave Young Reported-by: Freeman Zhang Reported-by: Emrah Demir Reported-by: Baoquan He Signed-off-by: Linus Torvalds

x86/mce: Avoid using object after free in genpool

2016-04-13T08:54:00+00:00

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

x86: remove the kernel code/data/bss resources from /proc/iomem

2016-04-06T20:45:07+00:00

Let's see if anybody even notices. I doubt anybody uses this, and it does expose addresses that should be randomized, so let's just remove the code. It's old and traditional, and it used to be cute, but we should have removed this long ago. If it turns out anybody notices and this breaks something, we'll have to revert this, and maybe we'll end up using other approaches instead (using %pK or similar). But removing unnecessary code is always the preferred option. Noted-by: Emrah Demir Signed-off-by: Linus Torvalds

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2016-04-03T11:32:28+00:00

Pull x86 fixes from Thomas Gleixner: "This lot contains: - Some fixups for the fallout of the topology consolidation which unearthed AMD/Intel inconsistencies - Documentation for the x86 topology management - Support for AMD advanced power management bits - Two simple cleanups removing duplicated code" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/cpu: Add advanced power management bits x86/thread_info: Merge two !__ASSEMBLY__ sections x86/cpufreq: Remove duplicated TDP MSR macro definitions x86/Documentation: Start documenting x86 topology x86/cpu: Get rid of compute_unit_id perf/x86/amd: Cleanup Fam10h NB event constraints x86/topology: Fix AMD core count

Merge branch 'acpi-processor'

2016-04-01T23:17:36+00:00

* acpi-processor: ACPI / processor: Request native thermal interrupt handling via _OSC

x86/cpu: Add advanced power management bits

2016-03-29T09:12:11+00:00

Bit 11 of CPUID 8000_0007 edx is processor feedback interface. Bit 12 of CPUID 8000_0007 edx is accumulated power. Print proper names in proc/cpuinfo Reported-and-tested-by: Borislav Petkov Signed-off-by: Huang Rui Cc: Tony Li Cc: Fenghua Yu Cc: Tony Luck Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: Andy Lutomirski Cc: Fengguang Wu Cc: Sherry Hurwitz Cc: Borislav Petkov Cc: "Len Brown" Link: http://lkml.kernel.org/r/1458871720-3209-1-git-send-email-ray.huang@amd.com Signed-off-by: Thomas Gleixner

x86/cpu: Get rid of compute_unit_id

2016-03-29T08:45:04+00:00

It is cpu_core_id anyway. Signed-off-by: Borislav Petkov Link: http://lkml.kernel.org/r/1458917557-8757-3-git-send-email-bp@alien8.de Signed-off-by: Thomas Gleixner

x86/topology: Fix AMD core count

2016-03-29T08:45:04+00:00

It turns out AMD gets x86_max_cores wrong when there are compute units. The issue is that Linux assumes: nr_logical_cpus = nr_cores * nr_siblings But AMD reports its CU unit as 2 cores, but then sets num_smp_siblings to 2 as well. Boris: fixup ras/mce_amd_inj.c too, to compute the Node Base Core properly, according to the new nomenclature. Fixes: 1f12e32f4cd5 ("x86/topology: Create logical package id") Reported-by: Xiong Zhou Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Cc: Andreas Herrmann Cc: Andy Lutomirski Link: http://lkml.kernel.org/r/20160317095220.GO6344@twins.programming.kicks-ass.net Signed-off-by: Thomas Gleixner

ACPI / processor: Request native thermal interrupt handling via _OSC

2016-03-26T01:00:38+00:00

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