linux-toradex.git/arch, branch v3.15.2

MIPS: KVM: Allocate at least 16KB for exception handlers

2014-06-26T19:17:34+00:00

commit 7006e2dfda9adfa40251093604db76d7e44263b3 upstream.

Each MIPS KVM guest has its own copy of the KVM exception vector. This
contains the TLB refill exception handler at offset 0x000, the general
exception handler at offset 0x180, and interrupt exception handlers at
offset 0x200 in case Cause_IV=1. A common handler is copied to offset
0x2000 and offset 0x3000 is used for temporarily storing k1 during entry
from guest.

However the amount of memory allocated for this purpose is calculated as
0x200 rounded up to the next page boundary, which is insufficient if 4KB
pages are in use. This can lead to the common handler at offset 0x2000
being overwritten and infinitely recursive exceptions on the next exit
from the guest.

Increase the minimum size from 0x200 to 0x4000 to cover the full use of
the page.

Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: Gleb Natapov 
Cc: kvm@vger.kernel.org
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc: Sanjay Lal 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

KVM: s390: Drop pending interrupts on guest exit

2014-06-26T19:17:34+00:00

commit 67335e63c9ef59e97b45a08b4a6a93767762031d upstream.

On hard exits (abort, sigkill) we have have some kvm_s390_interrupt_info
structures hanging around. Delete those on exit to avoid memory leaks.

Signed-off-by: Christian Borntraeger 
Reviewed-by: Thomas Huth 
Signed-off-by: Greg Kroah-Hartman

KVM: lapic: sync highest ISR to hardware apic on EOI

2014-06-26T19:17:34+00:00

commit fc57ac2c9ca8109ea97fcc594f4be436944230cc upstream.

When Hyper-V enlightenments are in effect, Windows prefers to issue an
Hyper-V MSR write to issue an EOI rather than an x2apic MSR write.
The Hyper-V MSR write is not handled by the processor, and besides
being slower, this also causes bugs with APIC virtualization.  The
reason is that on EOI the processor will modify the highest in-service
interrupt (SVI) field of the VMCS, as explained in section 29.1.4 of
the SDM; every other step in EOI virtualization is already done by
apic_send_eoi or on VM entry, but this one is missing.

We need to do the same, and be careful not to muck with the isr_count
and highest_isr_cache fields that are unused when virtual interrupt
delivery is enabled.

Reviewed-by: Yang Zhang 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: fix at91_sysirq_mask_rtc for sam9x5 SoCs

2014-06-26T19:17:34+00:00

commit 9dcc87fec8947308e0111c65dcd881e6aa5b1673 upstream.

sam9x5 SoCs have the following errata:
 "RTC: Interrupt Mask Register cannot be used
  Interrupt Mask Register read always returns 0."

Hence we should not rely on what IMR claims about already masked IRQs
and just disable all IRQs.

Signed-off-by: Boris BREZILLON 
Reported-by: Bryan Evenson 
Reviewed-by: Johan Hovold 
Acked-by: Nicolas Ferre 
Cc: Bryan Evenson 
Cc: Andrew Victor 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Alessandro Zummo 
Cc: Mark Roszko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

net: filter: fix sparc32 typo

2014-06-26T19:17:33+00:00

[ Upstream commit 588f5d629b3369aba88f52217d1c473a28fa7723 ]

Fixes: 569810d1e327 ("net: filter: fix typo in sparc BPF JIT")
Signed-off-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: filter: fix typo in sparc BPF JIT

2014-06-26T19:17:33+00:00

[ Upstream commit 569810d1e3278907264f5b115281fca3f0038d53 ]

fix typo in sparc codegen for SKF_AD_IFINDEX and SKF_AD_HATYPE
classic BPF extensions

Fixes: 2809a2087cc4 ("net: filter: Just In Time compiler for sparc")
Signed-off-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Revert "x86/smpboot: Initialize secondary CPU only if master CPU will wait for it"

2014-06-08T17:09:49+00:00

This reverts commit 3e1a878b7ccdb31da6d9d2b855c72ad87afeba3f.

It came in very late, and already has one reported failure: Sitsofe
reports that the current tree fails to boot on his EeePC, and bisected
it down to this.  Rather than waste time trying to figure out what's
wrong, just revert it.

Reported-by: Sitsofe Wheeler 
Cc: Igor Mammedov 
Cc: Toshi Kani 
Cc: Thomas Gleixner 
Acked-by: Ingo Molnar 
Signed-off-by: Linus Torvalds

x86/boot: EFI_MIXED should not prohibit loading above 4G

2014-06-07T16:31:00+00:00

commit 7d453eee36ae ("x86/efi: Wire up CONFIG_EFI_MIXED") introduced a
regression for the functionality to load kernels above 4G. The relevant
(incorrect) reasoning behind this change can be seen in the commit
message,

  "The xloadflags field in the bzImage header is also updated to reflect
  that the kernel supports both entry points by setting both of
  XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
  XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
  guaranteed to be addressable with 32-bits."

This is obviously bogus since 32-bit EFI loaders will never place the
kernel above the 4G mark. So this restriction is entirely unnecessary.

But things are worse than that - since we want to encourage people to
always compile with CONFIG_EFI_MIXED=y so that their kernels work out of
the box for both 32-bit and 64-bit firmware, commit 7d453eee36ae
effectively disables XLF_CAN_BE_LOADED_ABOVE_4G completely.

Remove the overzealous and superfluous restriction and restore the
XLF_CAN_BE_LOADED_ABOVE_4G functionality.

Cc: "H. Peter Anvin" 
Cc: Dave Young 
Cc: Vivek Goyal 
Signed-off-by: Matt Fleming 
Link: http://lkml.kernel.org/r/1402140380-15377-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin

Merge tag 'efi-urgent' into x86/urgent

2014-06-05T20:09:44+00:00

 * Fix earlyprintk=efi,keep support by switching to an ioremap() mapping
   of the framebuffer when early_ioremap() is no longer available and
   dropping __init from functions that may be invoked after
   free_initmem() - Dave Young

 * We shouldn't be exporting the EFI runtime map in sysfs if not using
   the new 1:1 EFI mapping code since in that case the mappings are not
   static across a kexec reboot - Dave Young

Signed-off-by: H. Peter Anvin

x86/smpboot: Initialize secondary CPU only if master CPU will wait for it

2014-06-05T14:33:08+00:00

Hang is observed on virtual machines during CPU hotplug,
especially in big guests with many CPUs. (It reproducible
more often if host is over-committed).

It happens because master CPU gives up waiting on
secondary CPU and allows it to run wild. As result
AP causes locking or crashing system. For example
as described here:

   https://lkml.org/lkml/2014/3/6/257

If master CPU have sent STARTUP IPI successfully,
and AP signalled to master CPU that it's ready
to start initialization, make master CPU wait
indefinitely till AP is onlined.
To ensure that AP won't ever run wild, make it
wait at early startup till master CPU confirms its
intention to wait for AP. If AP doesn't respond in 10
seconds, the master CPU will timeout and cancel
AP onlining.

Signed-off-by: Igor Mammedov 
Acked-by: Toshi Kani 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1401975765-22328-4-git-send-email-imammedo@redhat.com
Signed-off-by: Ingo Molnar