linux/arch/x86/include, branch v2.6.32.7

untangle the do_mremap() mess

2010-01-18T18:19:11Z

This backports the following upstream commits all as one patch: 54f5de709984bae0d31d823ff03de755f9dcac54 ecc1a8993751de4e82eb18640d631dae1f626bd6 1a0ef85f84feb13f07b604fcf5b90ef7c2b5c82f f106af4e90eadd76cfc0b5325f659619e08fb762 097eed103862f9c6a97f2e415e21d1134017b135 935874141df839c706cd6cdc438e85eb69d1525e 0ec62d290912bb4b989be7563851bc364ec73b56 c4caa778157dbbf04116f0ac2111e389b5cd7a29 2ea1d13f64efdf49319e86c87d9ba38c30902782 570dcf2c15463842e384eb597a87c1e39bead99b 564b3bffc619dcbdd160de597b0547a7017ea010 0067bd8a55862ac9dd212bd1c4f6f5bff1ca1301 f8b7256096a20436f6d0926747e3ac3d64c81d24 8c7b49b3ecd48923eb64ff57e07a1cdb74782970 9206de95b1ea68357996ec02be5db0638a0de2c1 2c6a10161d0b5fc047b5bd81b03693b9af99fab5 05d72faa6d13c9d857478a5d35c85db9adada685 bb52d6694002b9d632bb355f64daa045c6293a4e e77414e0aad6a1b063ba5e5750c582c75327ea6a aa65607373a4daf2010e8c3867b6317619f3c1a3 Backport done by Greg Kroah-Hartman. Only minor tweaks were needed. Cc: David S. Miller Cc: Hugh Dickins Cc: Paul Mundt Cc: Russell King Cc: Linus Torvalds Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

x86, msr: msrs_alloc/free for CONFIG_SMP=n

2010-01-06T23:05:12Z

commit 6ede31e03084ee084bcee073ef3d1136f68d0906 upstream. Randy Dunlap reported the following build error: "When CONFIG_SMP=n, CONFIG_X86_MSR=m: ERROR: "msrs_free" [drivers/edac/amd64_edac_mod.ko] undefined! ERROR: "msrs_alloc" [drivers/edac/amd64_edac_mod.ko] undefined!" This is due to the fact that is conditioned on CONFIG_SMP and in the UP case we have only the stubs in the header. Fork off SMP functionality into a new file (msr-smp.c) and build msrs_{alloc,free} unconditionally. Reported-by: Randy Dunlap Cc: H. Peter Anvin Signed-off-by: Borislav Petkov LKML-Reference: <20091216231625.GD27228@liondog.tnic> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86, msr: Add support for non-contiguous cpumasks

2010-01-06T23:05:11Z

commit 505422517d3f126bb939439e9d15dece94e11d2c upstream. The current rd/wrmsr_on_cpus helpers assume that the supplied cpumasks are contiguous. However, there are machines out there like some K8 multinode Opterons which have a non-contiguous core enumeration on each node (e.g. cores 0,2 on node 0 instead of 0,1), see http://www.gossamer-threads.com/lists/linux/kernel/1160268. This patch fixes out-of-bounds writes (see URL above) by adding per-CPU msr structs which are used on the respective cores. Additionally, two helpers, msrs_{alloc,free}, are provided for use by the callers of the MSR accessors. Cc: H. Peter Anvin Cc: Mauro Carvalho Chehab Cc: Aristeu Rozanski Cc: Randy Dunlap Cc: Doug Thompson Signed-off-by: Borislav Petkov LKML-Reference: <20091211171440.GD31998@aftab> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86, msr: Unify rdmsr_on_cpus/wrmsr_on_cpus

2010-01-06T23:05:07Z

commit b8a4754147d61f5359a765a3afd3eb03012aa052 upstream. Since rdmsr_on_cpus and wrmsr_on_cpus are almost identical, unify them into a common __rwmsr_on_cpus helper thus avoiding code duplication. While at it, convert cpumask_t's to const struct cpumask *. Signed-off-by: Borislav Petkov Signed-off-by: H. Peter Anvin Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: SGI UV: Fix writes to led registers on remote uv hubs

2010-01-06T23:03:47Z

commit 39d30770992895d55789de64bad2349510af68d0 upstream. The wrong address was being used to write the SCIR led regs on remote hubs. Also, there was an inconsistency between how BIOS and the kernel indexed these regs. Standardize on using the lower 6 bits of the APIC ID as the index. This patch fixes the problem of writing to an errant address to a cpu # >= 64. Signed-off-by: Mike Travis Reviewed-by: Jack Steiner Cc: Robin Holt Cc: Linus Torvalds LKML-Reference: <4B3922F9.3060905@sgi.com> [ v2: fix a number of annoying checkpatch artifacts and whitespace noise ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86, cpuid: Add "volatile" to asm in native_cpuid()

2010-01-06T23:03:19Z

commit 45a94d7cd45ed991914011919e7d40eb6d2546d1 upstream. xsave_cntxt_init() does something like: cpuid(0xd, ..); // find out what features FP/SSE/.. etc are supported xsetbv(); // enable the features known to OS cpuid(0xd, ..); // find out the size of the context for features enabled Depending on what features get enabled in xsetbv(), value of the cpuid.eax=0xd.ecx=0.ebx changes correspondingly (representing the size of the context that is enabled). As we don't have volatile keyword for native_cpuid(), gcc 4.1.2 optimizes away the second cpuid and the kernel continues to use the cpuid information obtained before xsetbv(), ultimately leading to kernel crash on processors supporting more state than the legacy FP/SSE. Add "volatile" for native_cpuid(). Signed-off-by: Suresh Siddha LKML-Reference: <1261009542.2745.55.camel@sbs-t61.sc.intel.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86: Under BIOS control, restore AP's APIC_LVTTHMR to the BSP value

2009-12-18T22:05:43Z

Upstream commit a2202aa29289db64ca7988b12343158b67b27f10. On platforms where bios handles the thermal monitor interrupt, APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS can't touch it. Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all the LVT entries except the mask bit. Essentially this results in all LVT entries including the thermal monitoring interrupt set to masked (clearing the bios programmed value for APIC_LVTTHMR). And this leads to kernel take over the thermal monitoring interrupt on AP's but not on BSP (leaving the bios programmed value only on BSP). As a result of this, we have seen system hangs when the thermal monitoring interrupt is generated. Fix this by reading the initial value of thermal LVT entry on BSP and if bios has taken over the control, then program the same value on all AP's and leave the thermal monitoring interrupt control on all the logical cpu's to the bios. Signed-off-by: Yong Wang Reviewed-by: Suresh Siddha Cc: Borislav Petkov Cc: Arjan van de Ven LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: Fix duplicated UV BAU interrupt vector

2009-12-18T22:03:45Z

commit 1d865fb728bd6bbcdfbd6ec1e2b8ade3b4805641 upstream. Interrupt vector 0xec has been doubly defined in irq_vectors.h It seems arbitrary whether LOCAL_PENDING_VECTOR or UV_BAU_MESSAGE is the higher number. As long as they are unique. If they are not unique we'll hit a BUG in alloc_system_vector(). Signed-off-by: Cliff Wickman LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

KVM: x86 emulator: limit instructions to 15 bytes

2009-12-18T22:03:32Z

commit eb3c79e64a70fb8f7473e30fa07e89c1ecc2c9bb upstream. While we are never normally passed an instruction that exceeds 15 bytes, smp games can cause us to attempt to interpret one, which will cause large latencies in non-preempt hosts. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6

2009-11-11T19:34:14Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: x86/PCI: Adjust GFP mask handling for coherent allocations PCI ASPM: fix oops on root port removal