linux/arch/x86, branch v3.4.2

x86: Reset the debug_stack update counter

2012-06-09T15:36:12Z

commit c0525a6972d3f1fb83058ef503e183475d6e4e26 upstream. When an NMI goes off and it sees that it preempted the debug stack, to keep the debug stack safe, it changes the IDT to point to one that does not modify the stack on breakpoint (to allow breakpoints in NMIs). But the variable that gets set to know to undo it on exit never gets cleared on exit. Thus every NMI will reset it on exit the first time it is done even if it does not need to be reset. [ Added H. Peter Anvin's suggestion to use this_cpu_read/write ] Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman

x86, x32, ptrace: Remove PTRACE_ARCH_PRCTL for x32

2012-06-09T15:36:12Z

commit bad1a753d4d4deb09d4bc0bac1dd4fc3298502e9 upstream. When I added x32 ptrace to 3.4 kernel, I also include PTRACE_ARCH_PRCTL support for x32 GDB For ARCH_GET_FS/GS, it takes a pointer to int64. But at user level, ARCH_GET_FS/GS takes a pointer to int32. So I have to add x32 ptrace to glibc to handle it with a temporary int64 passed to kernel and copy it back to GDB as int32. Roland suggested that PTRACE_ARCH_PRCTL is obsolete and x32 GDB should use fs_base and gs_base fields of user_regs_struct instead. Accordingly, remove PTRACE_ARCH_PRCTL completely from the x32 code to avoid possible memory overrun when pointer to int32 is passed to kernel. Link: http://lkml.kernel.org/r/CAMe9rOpDzHfS7NH7m1vmD9QRw8SSj4Sc%2BaNOgcWm_WJME2eRsQ@mail.gmail.com Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86, amd, xen: Avoid NULL pointer paravirt references

2012-06-09T15:36:09Z

commit 1ab46fd319bcf1fcd9fb6311727d532b580e4eba upstream. Stub out MSR methods that aren't actually needed. This fixes a crash as Xen Dom0 on AMD Trinity systems. A bigger patch should be added to remove the paravirt machinery completely for the methods which apparently have no users! Reported-by: Andre Przywara Link: http://lkml.kernel.org/r/20120530222356.GA28417@andromeda.dapyr.net Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

MCE: Fix vm86 handling for 32bit mce handler

2012-06-01T07:18:28Z

commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream. When running on 32bit the mce handler could misinterpret vm86 mode as ring 0. This can affect whether it does recovery or not; it was possible to panic when recovery was actually possible. Fix this by always forcing vm86 to look like ring 3. Signed-off-by: Andi Kleen Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman

x86/mce: Fix check for processor context when machine check was taken.

2012-06-01T07:18:26Z

commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream. Linus pointed out that there was no value is checking whether m->ip was zero - because zero is a legimate value. If we have a reliable (or faked in the VM86 case) "m->cs" we can use it to tell whether we were in user mode or kernelwhen the machine check hit. Reported-by: Linus Torvalds Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman

x86, relocs: Add jiffies and jiffies_64 to the relative whitelist

2012-06-01T07:18:26Z

commit ea17e7414bc62e8d3bde8d08e3df1d921c518c17 upstream. The symbol jiffies is created in the linker script as an alias to jiffies_64. Unfortunately this is done outside any section, and apparently GNU ld 2.21 doesn't carry the section with it, so we end up with an absolute symbol and therefore a broken kernel. Add jiffies and jiffies_64 to the whitelist. The most disturbing bit with this discovery is that it shows that we have had multiple linker bugs in this area crossing multiple generations, and have been silently building bad kernels for some time. Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.au Reported-by: Stephen Rothwell Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86-32, relocs: Whitelist more symbols for ld bug workaround

2012-06-01T07:18:26Z

commit fd952815307f0f272bf49fd364a7fd2f9992bc42 upstream. As noted in checkin: a3e854d95 x86, relocs: Workaround for binutils 2.22.52.0.1 section bug ld version 2.22.52.0.[12] can incorrectly promote relative symbols to absolute, if the output section they appear in is otherwise empty. Since checkin: 6520fe55 x86, realmode: 16-bit real-mode code support for relocs tool we actually check for this and error out rather than silently creating a kernel which will malfunction if relocated. Ingo found a configuration in which __start_builtin_fw triggered the warning. Go through the linker script sources and look for more symbols that could plausibly get bogusly promoted to absolute, and add them to the whitelist. In general, if the following error triggers: Invalid absolute R_386_32 relocation: ... then we should verify that is really meant to be relocated, and add it and any related symbols manually to the S_REL regexp. Please note that 6520fe55 does not introduce the error, only the check for the error -- without 6520fe55 this version of ld will simply produce a corrupt kernel if CONFIG_RELOCATABLE is set on x86-32. Reported-by: Ingo Molnar Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86, relocs: Build clean fix

2012-06-01T07:18:26Z

commit b2d668da9307c4c163dd603d2bb3cadb10f9fd37 upstream. relocs was not cleaned up when "make clean" is issued. This patch fixes the issue. Signed-off-by: Jarkko Sakkinen Link: http://lkml.kernel.org/r/1337622684-6834-1-git-send-email-jarkko.sakkinen@intel.com Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

xen: do not map the same GSI twice in PVHVM guests.

2012-06-01T07:18:25Z

commit 68c2c39a76b094e9b2773e5846424ea674bf2c46 upstream. PV on HVM guests map GSIs into event channels. At restore time the event channels are resumed by restore_pirqs. Device drivers might try to register the same GSI again through ACPI at restore time, but the GSI has already been mapped and bound by restore_pirqs. This patch detects these situations and avoids mapping the same GSI multiple times. Without this patch we get: (XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped and waste a pirq. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

perf/x86: Update event scheduling constraints for AMD family 15h models

2012-06-01T07:18:17Z

commit 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 upstream. This update is for newer family 15h cpu models from 0x02 to 0x1f. Signed-off-by: Robert Richter Acked-by: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1337337642-1621-1-git-send-email-robert.richter@amd.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman