linux-stable.git/arch, branch v3.18.35

xen/x86: actually allocate legacy interrupts on PV guests

2016-06-06T23:11:12+00:00

[ Upstream commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 ]

b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of legacy interrupts when actually nr_legacy_irqs() returns 0 after
probe_8259A(). Use NR_IRQS_LEGACY instead.

Signed-off-by: Stefano Stabellini 
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin

x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi

2016-06-06T23:11:12+00:00

[ Upstream commit 8abb850a03a3a8b11a0e92949e5b99d9cc178e35 ]

Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.

Signed-off-by: Jiang Liu 
Tested-by: Sander Eikelenboom 
Cc: Tony Luck 
Cc: xen-devel@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk 
Cc: David Vrabel 
Cc: Bjorn Helgaas 
Cc: Graeme Gregory 
Cc: Lv Zheng 
Link: http://lkml.kernel.org/r/1421720467-7709-4-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC

2016-06-06T23:11:06+00:00

[ Upstream commit e49d38488515057dba8f0c2ba4cfde5be4a7281f ]

Fix a build regression from commit c9017757c532 ("MIPS: init upper 64b
of vector registers when MSA is first used"):

arch/mips/built-in.o: In function `enable_restore_fp_context':
traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'

to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are
unable to figure out that calls to `_init_msa_upper' are indeed dead.
Of the many ways to tackle this failure choose the approach we have
already taken in `thread_msa_context_live'.

[ralf@linux-mips.org: Drop patch segment to junk file.]

Signed-off-by: Maciej W. Rozycki 
Cc: stable@vger.kernel.org # v3.16+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13271/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

MIPS: math-emu: Fix jalr emulation when rd == $0

2016-06-06T23:11:04+00:00

[ Upstream commit ab4a92e66741b35ca12f8497896bafbe579c28a1 ]

When emulating a jalr instruction with rd == $0, the code in
isBranchInstr was incorrectly writing to GPR $0 which should actually
always remain zeroed. This would lead to any further instructions
emulated which use $0 operating on a bogus value until the task is next
context switched, at which point the value of $0 in the task context
would be restored to the correct zero by a store in SAVE_SOME. Fix this
by not writing to rd if it is $0.

Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.")
Signed-off-by: Paul Burton 
Cc: Maciej W. Rozycki 
Cc: James Hogan 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable  # v3.10
Patchwork: https://patchwork.linux-mips.org/patch/13160/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover()

2016-06-06T23:11:04+00:00

[ Upstream commit 5a0cdbfd17b90a89c64a71d8aec9773ecdb20d0d ]

The function eeh_pe_reset_and_recover() is used to recover EEH
error when the passthrou device are transferred to guest and
backwards. The content in the device's config space will be lost
on PE reset issued in the middle of the recovery. The function
saves/restores it before/after the reset. However, config access
to some adapters like Broadcom BCM5719 at this point will causes
fenced PHB. The config space is always blocked and we save 0xFF's
that are restored at late point. The memory BARs are totally
corrupted, causing another EEH error upon access to one of the
memory BARs.

This restores the config space on those adapters like BCM5719
from the content saved to the EEH device when it's populated,
to resolve above issue.

Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
Cc: stable@vger.kernel.org #v3.18+
Signed-off-by: Gavin Shan 
Reviewed-by: Russell Currey 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin

powerpc/eeh: Don't report error in eeh_pe_reset_and_recover()

2016-06-06T23:11:03+00:00

[ Upstream commit affeb0f2d3a9af419ad7ef4ac782e1540b2f7b28 ]

The function eeh_pe_reset_and_recover() is used to recover EEH
error when the passthrough device are transferred to guest and
backwards, meaning the device's driver is vfio-pci or none.
When the driver is vfio-pci that provides error_detected() error
handler only, the handler simply stops the guest and it's not
expected behaviour. On the other hand, no error handlers will
be called if we don't have a bound driver.

This ignores the error handler in eeh_pe_reset_and_recover()
that reports the error to device driver to avoid the exceptional
behaviour.

Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
Cc: stable@vger.kernel.org #v3.18+
Signed-off-by: Gavin Shan 
Reviewed-by: Russell Currey 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin

MIPS: KVM: Fix timer IRQ race when writing CP0_Compare

2016-06-06T23:11:02+00:00

[ Upstream commit b45bacd2d048f405c7760e5cc9b60dd67708734f ]

Writing CP0_Compare clears the timer interrupt pending bit
(CP0_Cause.TI), but this wasn't being done atomically. If a timer
interrupt raced with the write of the guest CP0_Compare, the timer
interrupt could end up being pending even though the new CP0_Compare is
nowhere near CP0_Count.

We were already updating the hrtimer expiry with
kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
kvm_mips_resume_hrtimer(). Close the race window by expanding out
kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
CP0_Compare between the freeze and resume. Since the pending timer
interrupt should not be cleared when CP0_Compare is written via the KVM
user API, an ack argument is added to distinguish the source of the
write.

Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim KrÄmÃ¡Å™" 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc:  # 3.16.x-
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin

MIPS: KVM: Fix timer IRQ race when freezing timer

2016-06-06T23:11:01+00:00

[ Upstream commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 ]

There's a particularly narrow and subtle race condition when the
software emulated guest timer is frozen which can allow a guest timer
interrupt to be missed.

This happens due to the hrtimer expiry being inexact, so very
occasionally the freeze time will be after the moment when the emulated
CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
be generated), but before the moment when the hrtimer is due to expire
(so no IRQ is generated). The IRQ won't be generated when the timer is
resumed either, since the resume CP0_Count will already match CP0_Compare.

With VZ guests in particular this is far more likely to happen, since
the soft timer may be frozen frequently in order to restore the timer
state to the hardware guest timer. This happens after 5-10 hours of
guest soak testing, resulting in an overflow in guest kernel timekeeping
calculations, hanging the guest. A more focussed test case to
intentionally hit the race (with the help of a new hypcall to cause the
timer state to migrated between hardware & software) hits the condition
fairly reliably within around 30 seconds.

Instead of relying purely on the inexact hrtimer expiry to determine
whether an IRQ should be generated, read the guest CP0_Compare and
directly check whether the freeze time is before or after it. Only if
CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
determine whether the last IRQ has already been generated (which will
have pushed back the expiry by one timer period).

Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim KrÄmÃ¡Å™" 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc:  # 3.16.x-
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin

MIPS: Avoid using unwind_stack() with usermode

2016-06-03T15:30:38+00:00

[ Upstream commit 81a76d7119f63c359750e4adeff922a31ad1135f ]

When showing backtraces in response to traps, for example crashes and
address errors (usually unaligned accesses) when they are set in debugfs
to be reported, unwind_stack will be used if the PC was in the kernel
text address range. However since EVA it is possible for user and kernel
address ranges to overlap, and even without EVA userland can still
trigger an address error by jumping to a KSeg0 address.

Adjust the check to also ensure that it was running in kernel mode. I
don't believe any harm can come of this problem, since unwind_stack() is
sufficiently defensive, however it is only meant for unwinding kernel
code, so to be correct it should use the raw backtracing instead.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/11701/
Signed-off-by: Ralf Baechle 
(cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
Signed-off-by: Sasha Levin

MIPS: Don't unwind to user mode with EVA

2016-06-03T15:30:37+00:00

[ Upstream commit a816b306c62195b7c43c92cb13330821a96bdc27 ]

When unwinding through IRQs and exceptions, the unwinding only continues
if the PC is a kernel text address, however since EVA it is possible for
user and kernel address ranges to overlap, potentially allowing
unwinding to continue to user mode if the user PC happens to be in the
kernel text address range.

Adjust the check to also ensure that the register state from before the
exception is actually running in kernel mode, i.e. !user_mode(regs).

I don't believe any harm can come of this problem, since the PC is only
output, the stack pointer is checked to ensure it resides within the
task's stack page before it is dereferenced in search of the return
address, and the return address register is similarly only output (if
the PC is in a leaf function or the beginning of a non-leaf function).

However unwind_stack() is only meant for unwinding kernel code, so to be
correct the unwind should stop there.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/11700/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin