linux-stable.git/arch, branch v4.4.16

s390: fix test_fp_ctl inline assembly contraints

2016-07-27T16:47:39+00:00

commit bcf4dd5f9ee096bd1510f838dd4750c35df4e38b upstream.

The test_fp_ctl function is used to test if a given value is a valid
floating-point control. The inline assembly in test_fp_ctl uses an
incorrect constraint for the 'orig_fpc' variable. If the compiler
chooses the same register for 'fpc' and 'orig_fpc' the test_fp_ctl()
function always returns true. This allows user space to trigger
kernel oopses with invalid floating-point control values on the
signal stack.

This problem has been introduced with git commit 4725c86055f5bbdcdf
"s390: fix save and restore of the floating-point-control register"

Reviewed-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: fix HW I/O coherency related deadlocks

2016-07-27T16:47:39+00:00

commit c5379ba8fccd99d5f99632c789f0393d84a57805 upstream.

Until now, our understanding for HW I/O coherency to work on the
Cortex-A9 based Marvell SoC was that only the PCIe regions should be
mapped strongly-ordered. However, we were still encountering some
deadlocks, especially when testing the CESA crypto engine. After
checking with the HW designers, it was concluded that all the MMIO
registers should be mapped as strongly ordered for the HW I/O coherency
mechanism to work properly.

This fixes some easy to reproduce deadlocks with the CESA crypto engine
driver (dmcrypt on a sufficiently large disk partition).

Tested-by: Terry Stockert 
Tested-by: Romain Perier 
Cc: Terry Stockert 
Cc: Romain Perier 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: armada-38x: fix MBUS_ID for crypto SRAM on Armada 385 Linksys

2016-07-27T16:47:39+00:00

commit 929e604efa3dc0522214e0dc18984be23993e9f0 upstream.

When the support for the Marvell crypto engine was added in the Device
Tree of the various Armada 385 Device Tree files in commit
d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x
boards"), a typo was made in the MBus window attributes for the Armada
385 Linksys board: 0x09/0x05 are used instead of 0x19/0x15. This commit
fixes this typo, which makes the CESA engines operational on Armada 385
Linksys boards.

Reported-by: Terry Stockert 
Cc: Terry Stockert 
Cc: Imre Kaloz 
Cc: Boris Brezillon 
Fixes: d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards")
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: sunxi/dt: make the CHIP inherit from allwinner,sun5i-a13

2016-07-27T16:47:38+00:00

commit 5fc39d347267bd029fcc9099c70e2fe2d53130e9 upstream.

The sun4i-timer driver registers its sched_clock only if the machine is
compatible with "allwinner,sun5i-a13", "allwinner,sun5i-a10s" or
"allwinner,sun4i-a10".
Add the missing "allwinner,sun5i-a13" string to the machine compatible.

Signed-off-by: Boris Brezillon 
Fixes: 465a225fb2af ("ARM: sun5i: Add C.H.I.P DTS")
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

perf/x86: Fix undefined shift on 32-bit kernels

2016-07-27T16:47:36+00:00

commit 6d6f2833bfbf296101f9f085e10488aef2601ba5 upstream.

Jim reported:

	UBSAN: Undefined behaviour in arch/x86/events/intel/core.c:3708:12
	shift exponent 35 is too large for 32-bit type 'long unsigned int'

The use of 'unsigned long' type obviously is not correct here, make it
'unsigned long long' instead.

Reported-by: Jim Cromie 
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: H. Peter Anvin 
Cc: Imre Palik 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: 2c33645d366d ("perf/x86: Honor the architectural performance monitoring version")
Link: http://lkml.kernel.org/r/1462974711-10037-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Ingo Molnar 
Cc: Kevin Christopher 
Signed-off-by: Greg Kroah-Hartman

arm64: Rework valid_user_regs

2016-07-27T16:47:33+00:00

commit dbd4d7ca563fd0a8949718d35ce197e5642d5d9d upstream.

We validate pstate using PSR_MODE32_BIT, which is part of the
user-provided pstate (and cannot be trusted). Also, we conflate
validation of AArch32 and AArch64 pstate values, making the code
difficult to reason about.

Instead, validate the pstate value based on the associated task. The
task may or may not be current (e.g. when using ptrace), so this must be
passed explicitly by callers. To avoid circular header dependencies via
sched.h, is_compat_task is pulled out of asm/ptrace.h.

To make the code possible to reason about, the AArch64 and AArch32
validation is split into separate functions. Software must respect the
RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
architected meaning writes may be permitted (potentially with additional
validation).

Signed-off-by: Mark Rutland 
Acked-by: Will Deacon 
Cc: Dave Martin 
Cc: James Morse 
Cc: Peter Maydell 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
[ rebased for v4.1+
  This avoids a user-triggerable Oops() if a task is switched to a mode
  not supported by the kernel (e.g. switching a 64-bit task to AArch32).
]
Signed-off-by: James Morse 
Reviewed-by: Mark Rutland  [backport]
Signed-off-by: Greg Kroah-Hartman

KVM: nVMX: VMX instructions: fix segment checks when L1 is in long mode.

2016-07-27T16:47:32+00:00

commit ff30ef40deca4658e27b0c596e7baf39115e858f upstream.

I couldn't get Xen to boot a L2 HVM when it was nested under KVM - it was
getting a GP(0) on a rather unspecial vmread from Xen:

     (XEN) ----[ Xen-4.7.0-rc  x86_64  debug=n  Not tainted ]----
     (XEN) CPU:    1
     (XEN) RIP:    e008:[] vmx_get_segment_register+0x14e/0x450
     (XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor (d1v0)
     (XEN) rax: ffff82d0801e6288   rbx: ffff83003ffbfb7c   rcx: fffffffffffab928
     (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: ffff83000bdd0000
     (XEN) rbp: ffff83000bdd0000   rsp: ffff83003ffbfab0   r8:  ffff830038813910
     (XEN) r9:  ffff83003faf3958   r10: 0000000a3b9f7640   r11: ffff83003f82d418
     (XEN) r12: 0000000000000000   r13: ffff83003ffbffff   r14: 0000000000004802
     (XEN) r15: 0000000000000008   cr0: 0000000080050033   cr4: 00000000001526e0
     (XEN) cr3: 000000003fc79000   cr2: 0000000000000000
     (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
     (XEN) Xen code around  (vmx_get_segment_register+0x14e/0x450):
     (XEN)  00 00 41 be 02 48 00 00 <44> 0f 78 74 24 08 0f 86 38 56 00 00 b8 08 68 00
     (XEN) Xen stack trace from rsp=ffff83003ffbfab0:

     ...

     (XEN) Xen call trace:
     (XEN)    [] vmx_get_segment_register+0x14e/0x450
     (XEN)    [] get_page_from_gfn_p2m+0x165/0x300
     (XEN)    [] hvmemul_get_seg_reg+0x52/0x60
     (XEN)    [] hvm_emulate_prepare+0x53/0x70
     (XEN)    [] handle_mmio+0x2b/0xd0
     (XEN)    [] emulate.c#_hvm_emulate_one+0x111/0x2c0
     (XEN)    [] handle_hvm_io_completion+0x274/0x2a0
     (XEN)    [] __get_gfn_type_access+0xfa/0x270
     (XEN)    [] timer.c#add_entry+0x4b/0xb0
     (XEN)    [] timer.c#remove_entry+0x7c/0x90
     (XEN)    [] hvm_do_resume+0x23/0x140
     (XEN)    [] vmx_do_resume+0xa7/0x140
     (XEN)    [] context_switch+0x13b/0xe40
     (XEN)    [] schedule.c#schedule+0x22e/0x570
     (XEN)    [] softirq.c#__do_softirq+0x5c/0x90
     (XEN)    [] domain.c#idle_loop+0x25/0x50
     (XEN)
     (XEN)
     (XEN) ****************************************
     (XEN) Panic on CPU 1:
     (XEN) GENERAL PROTECTION FAULT
     (XEN) [error_code=0000]
     (XEN) ****************************************

Tracing my host KVM showed it was the one injecting the GP(0) when
emulating the VMREAD and checking the destination segment permissions in
get_vmx_mem_address():

     3)               |    vmx_handle_exit() {
     3)               |      handle_vmread() {
     3)               |        nested_vmx_check_permission() {
     3)               |          vmx_get_segment() {
     3)   0.074 us    |            vmx_read_guest_seg_base();
     3)   0.065 us    |            vmx_read_guest_seg_selector();
     3)   0.066 us    |            vmx_read_guest_seg_ar();
     3)   1.636 us    |          }
     3)   0.058 us    |          vmx_get_rflags();
     3)   0.062 us    |          vmx_read_guest_seg_ar();
     3)   3.469 us    |        }
     3)               |        vmx_get_cs_db_l_bits() {
     3)   0.058 us    |          vmx_read_guest_seg_ar();
     3)   0.662 us    |        }
     3)               |        get_vmx_mem_address() {
     3)   0.068 us    |          vmx_cache_reg();
     3)               |          vmx_get_segment() {
     3)   0.074 us    |            vmx_read_guest_seg_base();
     3)   0.068 us    |            vmx_read_guest_seg_selector();
     3)   0.071 us    |            vmx_read_guest_seg_ar();
     3)   1.756 us    |          }
     3)               |          kvm_queue_exception_e() {
     3)   0.066 us    |            kvm_multiple_exception();
     3)   0.684 us    |          }
     3)   4.085 us    |        }
     3)   9.833 us    |      }
     3) + 10.366 us   |    }

Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software
Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine
Control Structure", I found that we're enforcing that the destination
operand is NOT located in a read-only data segment or any code segment when
the L1 is in long mode - BUT that check should only happen when it is in
protected mode.

Shuffling the code a bit to make our emulation follow the specification
allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests
without problems.

Fixes: f9eb4af67c9d ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions")
Signed-off-by: Quentin Casasnovas 
Cc: Eugene Korenevsky 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

ARCv2: LLSC: software backoff is NOT needed starting HS2.1c

2016-07-27T16:47:31+00:00

commit b31ac42697bef4a3aa5d0aa42375a55657f57174 upstream.

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARCv2: Check for LL-SC livelock only if LLSC is enabled

2016-07-27T16:47:31+00:00

commit 4d0cb15fccd1db9dac0c964b2ccf10874e69f5b8 upstream.

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

MIPS: KVM: Fix modular KVM under QEMU

2016-07-27T16:47:30+00:00

commit 797179bc4fe06c89e47a9f36f886f68640b423f8 upstream.

Copy __kvm_mips_vcpu_run() into unmapped memory, so that we can never
get a TLB refill exception in it when KVM is built as a module.

This was observed to happen with the host MIPS kernel running under
QEMU, due to a not entirely transparent optimisation in the QEMU TLB
handling where TLB entries replaced with TLBWR are copied to a separate
part of the TLB array. Code in those pages continue to be executable,
but those mappings persist only until the next ASID switch, even if they
are marked global.

An ASID switch happens in __kvm_mips_vcpu_run() at exception level after
switching to the guest exception base. Subsequent TLB mapped kernel
instructions just prior to switching to the guest trigger a TLB refill
exception, which enters the guest exception handlers without updating
EPC. This appears as a guest triggered TLB refill on a host kernel
mapped (host KSeg2) address, which is not handled correctly as user
(guest) mode accesses to kernel (host) segments always generate address
error exceptions.

Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Ralf Baechle 
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman