linux/arch, branch v3.4.3

crypto: aesni-intel - fix unaligned cbc decrypt for x86-32

2012-06-17T18:21:24Z

commit 7c8d51848a88aafdb68f42b6b650c83485ea2f84 upstream. The 32 bit variant of cbc(aes) decrypt is using instructions requiring 128 bit aligned memory locations but fails to ensure this constraint in the code. Fix this by loading the data into intermediate registers with load unaligned instructions. This fixes reported general protection faults related to aesni. References: https://bugzilla.kernel.org/show_bug.cgi?id=43223 Reported-by: Daniel Signed-off-by: Mathias Krause Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

x86, MCE, AMD: Make APIC LVT thresholding interrupt optional

2012-06-17T18:21:23Z

commit f227d4306cf30e1d5b6f231e8ef9006c34f3d186 upstream. Currently, the APIC LVT interrupt for error thresholding is implicitly enabled. However, there are models in the F15h range which do not enable it. Make the code machinery which sets up the APIC interrupt support an optional setting and add an ->interrupt_capable member to the bank representation mirroring that capability and enable the interrupt offset programming only if it is true. Simplify code and fixup comment style while at it. Signed-off-by: Borislav Petkov Cc: Robert Richter Signed-off-by: Greg Kroah-Hartman

x86/uv: Fix UV2 BAU legacy mode

2012-06-17T18:21:23Z

commit d5d2d2eea84b0d8450b082edbc3dbde41fb8bfd8 upstream. The SGI Altix UV2 BAU (Broadcast Assist Unit) as used for tlb-shootdown (selective broadcast mode) always uses UV2 broadcast descriptor format. There is no need to clear the 'legacy' (UV1) mode, because the hardware always uses UV2 mode for selective broadcast. But the BIOS uses general broadcast and legacy mode, and the hardware pays attention to the legacy mode bit for general broadcast. So the kernel must not clear that mode bit. Signed-off-by: Cliff Wickman Link: http://lkml.kernel.org/r/E1SccoO-0002Lh-Cb@eag09.americas.sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

powerpc: Fix kernel panic during kernel module load

2012-06-17T18:21:22Z

commit 3c75296562f43e6fbc6cddd3de948a7b3e4e9bcf upstream. This fixes a problem which can causes kernel oopses while loading a kernel module. According to the PowerPC EABI specification, GPR r11 is assigned the dedicated function to point to the previous stack frame. In the powerpc-specific kernel module loader, do_plt_call() (in arch/powerpc/kernel/module_32.c), GPR r11 is also used to generate trampoline code. This combination crashes the kernel, in the case where the compiler chooses to use a helper function for saving GPRs on entry, and the module loader has placed the .init.text section far away from the .text section, meaning that it has to generate a trampoline for functions in the .init.text section to call the GPR save helper. Because the trampoline trashes r11, references to the stack frame using r11 can cause an oops. The fix just uses GPR r12 instead of GPR r11 for generating the trampoline code. According to the statements from Freescale, this is safe from an EABI perspective. I've tested the fix for kernel 2.6.33 on MPC8541. Signed-off-by: Steffen Rumler [paulus@samba.org: reworded the description] Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman

powerpc/time: Sanity check of decrementer expiration is necessary

2012-06-17T18:21:22Z

commit 860aed25a1f0936d4852ab936252b47cd1e630f1 upstream. This reverts 68568add2c ("powerpc/time: Remove unnecessary sanity check of decrementer expiration"). We do need to check whether we have reached the expiration time of the next event, because we sometimes get an early decrementer interrupt, most notably when we set the decrementer to 1 in arch_irq_work_raise(). The effect of not having the sanity check is that if timer_interrupt() gets called early, we leave the decrementer set to its maximum value, which means we then don't get any more decrementer interrupts for about 4 seconds (or longer, depending on timebase frequency). I saw these pauses as a consequence of getting a stray hypervisor decrementer interrupt left over from exiting a KVM guest. This isn't quite a straight revert because of changes to the surrounding code, but it restores the same algorithm as was previously used. Acked-by: Anton Blanchard Acked-by: Benjamin Herrenschmidt Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman

IA64: Add cmpxchg.h to exported userspace headers

2012-06-09T15:36:19Z

commit 98e4cff73a18af27f0d40d0b0d37f105dfc1994a upstream. Fixes klibc build on ia64 after 85f8f7759e418c814ee2ceacf73eddb9bed39492. Cc: Paul Gortmaker Signed-off-by: maximilian attems Signed-off-by: Tony Luck Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

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

ixp4xx: fix compilation by adding gpiolib support

2012-06-09T15:36:08Z

commit 9dde0ae3769875ec1370cb316e50c54b57d52c1a upstream. Once again, ixp4xx no longer even compiles. This patch fixes the issue by converting over to gpiolib. This patch was first made by Imre and posted by Marc, and I added in Russell's suggestion to empty the gpio header file. This fix should also go for 3.1, 3.2, 3.3, and 3.4. Signed-off-by: Richard Cochran Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman