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

Revert "s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL"

2016-07-27T15:42:24+00:00

commit 5419447e2142d6ed68c9f5c1a28630b3a290a845 upstream.

This reverts commit 852ffd0f4e23248b47531058e531066a988434b5.

There are use cases where an intermediate boot kernel (1) uses kexec
to boot the final production kernel (2). For this scenario we should
provide the original boot information to the production kernel (2).
Therefore clearing the boot information during kexec() should not
be done.

Reported-by: Steffen Maier 
Signed-off-by: Michael Holzheu 
Reviewed-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

s390: fix test_fp_ctl inline assembly contraints

2016-07-27T15:42:24+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-27T15:42:23+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-27T15:42:23+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-27T15:42:23+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

arm64: kernel: Save and restore UAO and addr_limit on exception entry

2016-07-27T15:42:16+00:00

commit e19a6ee2460bdd0d0055a6029383422773f9999a upstream.

If we take an exception while at EL1, the exception handler inherits
the original context's addr_limit and PSTATE.UAO values. To be consistent
always reset addr_limit and PSTATE.UAO on (re-)entry to EL1. This
prevents accidental re-use of the original context's addr_limit.

Based on a similar patch for arm from Russell King.

Acked-by: Will Deacon 
Reviewed-by: Mark Rutland 
Signed-off-by: James Morse 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: mm: remove page_mapping check in __sync_icache_dcache

2016-07-27T15:42:16+00:00

commit 20c27a4270c775d7ed661491af8ac03264d60fc6 upstream.

__sync_icache_dcache unconditionally skips the cache maintenance for
anonymous pages, under the assumption that flushing is only required in
the presence of D-side aliases [see 7249b79f6b4cc ("arm64: Do not flush
the D-cache for anonymous pages")].

Unfortunately, this breaks migration of anonymous pages holding
self-modifying code, where userspace cannot be reasonably expected to
reissue maintenance instructions in response to a migration.

This patch fixes the problem by removing the broken page_mapping(page)
check from the cache syncing code, otherwise we may end up fetching and
executing stale instructions from the PoU.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Reviewed-by: Catalin Marinas 
Signed-off-by: Shaokun Zhang 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: fix dump_instr when PAN and UAO are in use

2016-07-27T15:42:16+00:00

commit c5cea06be060f38e5400d796e61cfc8c36e52924 upstream.

If the kernel is set to show unhandled signals, and a user task does not
handle a SIGILL as a result of an instruction abort, we will attempt to
log the offending instruction with dump_instr before killing the task.

We use dump_instr to log the encoding of the offending userspace
instruction. However, dump_instr is also used to dump instructions from
kernel space, and internally always switches to KERNEL_DS before dumping
the instruction with get_user. When both PAN and UAO are in use, reading
a user instruction via get_user while in KERNEL_DS will result in a
permission fault, which leads to an Oops.

As we have regs corresponding to the context of the original instruction
abort, we can inspect this and only flip to KERNEL_DS if the original
abort was taken from the kernel, avoiding this issue. At the same time,
remove the redundant (and incorrect) comments regarding the order
dump_mem and dump_instr are called in.

Cc: Catalin Marinas 
Cc: James Morse 
Cc: Robin Murphy 
Signed-off-by: Mark Rutland 
Reported-by: Vladimir Murzin 
Tested-by: Vladimir Murzin 
Fixes: 57f4959bad0a154a ("arm64: kernel: Add support for User Access Override")
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

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

2016-07-27T15:42:14+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

KVM: arm/arm64: Stop leaking vcpu pid references

2016-07-27T15:42:14+00:00

commit 591d215afcc2f94e8e2c69a63c924c044677eb31 upstream.

kvm provides kvm_vcpu_uninit(), which amongst other things, releases the
last reference to the struct pid of the task that was last running the vcpu.

On arm64 built with CONFIG_DEBUG_KMEMLEAK, starting a guest with kvmtool,
then killing it with SIGKILL results (after some considerable time) in:
> cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff80007d5ea080 (size 128):
>  comm "lkvm", pid 2025, jiffies 4294942645 (age 1107.776s)
>  hex dump (first 32 bytes):
>    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>  backtrace:
>    [] create_object+0xfc/0x278
>    [] kmemleak_alloc+0x34/0x70
>    [] kmem_cache_alloc+0x16c/0x1d8
>    [] alloc_pid+0x34/0x4d0
>    [] copy_process.isra.6+0x79c/0x1338
>    [] _do_fork+0x74/0x320
>    [] SyS_clone+0x18/0x20
>    [] el0_svc_naked+0x24/0x28
>    [] 0xffffffffffffffff

On x86 kvm_vcpu_uninit() is called on the path from kvm_arch_destroy_vm(),
on arm no equivalent call is made. Add the call to kvm_arch_vcpu_free().

Signed-off-by: James Morse 
Fixes: 749cf76c5a36 ("KVM: ARM: Initial skeleton to compile KVM support")
Acked-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman