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

pstore: Fix flags to enable dumps on powerpc

2017-05-20T12:49:51+00:00

commit 041939c1ec54208b42f5cd819209173d52a29d34 upstream.

After commit c950fd6f201a kernel registers pstore write based on flag set.
Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG) is not set for
powerpc architecture. On panic, kernel doesn't write message to
/fs/pstore/dmesg*(Entry doesn't gets created at all).

This patch enables pstore write for powerpc architecture by setting
PSTORE_FLAGS_DMESG flag.

Fixes: c950fd6f201a ("pstore: Split pstore fragile flags")
Signed-off-by: Ankit Kumar 
Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Fix decoding of Rt/Rt2 when trapping AArch32 CP accesses

2017-05-20T12:49:42+00:00

commit c667186f1c01ca8970c785888868b7ffd74e51ee upstream.

Our 32bit CP14/15 handling inherited some of the ARMv7 code for handling
the trapped system registers, completely missing the fact that the
fields for Rt and Rt2 are now 5 bit wide, and not 4...

Let's fix it, and provide an accessor for the most common Rt case.

Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

KVM: arm/arm64: fix races in kvm_psci_vcpu_on

2017-05-20T12:49:42+00:00

commit 6c7a5dce22b3f3cc44be098e2837fa6797edb8b8 upstream.

Fix potential races in kvm_psci_vcpu_on() by taking the kvm->lock
mutex.  In general, it's a bad idea to allow more than one PSCI_CPU_ON
to process the same target VCPU at the same time.  One such problem
that may arise is that one PSCI_CPU_ON could be resetting the target
vcpu, which fills the entire sys_regs array with a temporary value
including the MPIDR register, while another looks up the VCPU based
on the MPIDR value, resulting in no target VCPU found.  Resolves both
races found with the kvm-unit-tests/arm/psci unit test.

Reviewed-by: Marc Zyngier 
Reviewed-by: Christoffer Dall 
Reported-by: Levente Kurusa 
Suggested-by: Christoffer Dall 
Signed-off-by: Andrew Jones 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

Revert "KVM: Support vCPU-based gfn->hva cache"

2017-05-20T12:49:42+00:00

commit 4e335d9e7ddbcf83d03e7fbe65797ebed2272c18 upstream.

This reverts commit bbd6411513aa8ef3ea02abab61318daf87c1af1e.

I've been sitting on this revert for too long and it unfortunately
missed 4.11.  It's also the reason why I haven't merged ring-based
dirty tracking for 4.12.

Using kvm_vcpu_memslots in kvm_gfn_to_hva_cache_init and
kvm_vcpu_write_guest_offset_cached means that the MSR value can
now be used to access SMRAM, simply by making it point to an SMRAM
physical address.  This is problematic because it lets the guest
OS overwrite memory that it shouldn't be able to touch.

Fixes: bbd6411513aa8ef3ea02abab61318daf87c1af1e
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: fix user triggerable warning in kvm_apic_accept_events()

2017-05-20T12:49:42+00:00

commit 28bf28887976d8881a3a59491896c718fade7355 upstream.

If we already entered/are about to enter SMM, don't allow switching to
INIT/SIPI_RECEIVED, otherwise the next call to kvm_apic_accept_events()
will report a warning.

Same applies if we are already in MP state INIT_RECEIVED and SMM is
requested to be turned on. Refuse to set the VCPU events in this case.

Fixes: cd7764fe9f73 ("KVM: x86: latch INITs while in system management mode")
Reported-by: Dmitry Vyukov 
Signed-off-by: David Hildenbrand 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

perf/x86: Fix Broadwell-EP DRAM RAPL events

2017-05-20T12:49:42+00:00

commit 33b88e708e7dfa58dc896da2a98f5719d2eb315c upstream.

It appears as though the Broadwell-EP DRAM units share the special
units quirk with Haswell-EP/KNL.

Without this patch, you get really high results (a single DRAM using 20W
of power).

The powercap driver in drivers/powercap/intel_rapl.c already has this
change.

Signed-off-by: Vince Weaver 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

um: Fix PTRACE_POKEUSER on x86_64

2017-05-20T12:49:42+00:00

commit 9abc74a22d85ab29cef9896a2582a530da7e79bf upstream.

This is broken since ever but sadly nobody noticed.
Recent versions of GDB set DR_CONTROL unconditionally and
UML dies due to a heap corruption. It turns out that
the PTRACE_POKEUSER was copy&pasted from i386 and assumes
that addresses are 4 bytes long.

Fix that by using 8 as address size in the calculation.

Reported-by: jie cao 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

x86, pmem: Fix cache flushing for iovec write < 8 bytes

2017-05-20T12:49:42+00:00

commit 8376efd31d3d7c44bd05be337adde023cc531fa1 upstream.

Commit 11e63f6d920d added cache flushing for unaligned writes from an
iovec, covering the first and last cache line of a >= 8 byte write and
the first cache line of a < 8 byte write.  But an unaligned write of
2-7 bytes can still cover two cache lines, so make sure we flush both
in that case.

Fixes: 11e63f6d920d ("x86, pmem: fix broken __copy_user_nocache ...")
Signed-off-by: Ben Hutchings 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup

2017-05-20T12:49:42+00:00

commit d594aa0277e541bb997aef0bc0a55172d8138340 upstream.

The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
when the bootloader does not setup/provide a stack for the early boot components
is not "enough".

The setup code executing as part of early kernel startup code, uses the stack
beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
section. This is exposed mostly in the early video setup code, where
it was corrupting BSS variables like force_x, force_y, which in-turn affected
kernel parameters such as screen_info (screen_info.orig_video_cols) and
later caused an exception/panic in console_init().

Most recent boot loaders setup the stack for early boot components, so this
stack overwriting into BSS section issue has not been exposed.

Signed-off-by: Ashish Kalra 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.local
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xen: adjust early dom0 p2m handling to xen hypervisor behavior

2017-05-20T12:49:39+00:00

commit 69861e0a52f8733355ce246f0db15e1b240ad667 upstream.

When booted as pv-guest the p2m list presented by the Xen is already
mapped to virtual addresses. In dom0 case the hypervisor might make use
of 2M- or 1G-pages for this mapping. Unfortunately while being properly
aligned in virtual and machine address space, those pages might not be
aligned properly in guest physical address space.

So when trying to obtain the guest physical address of such a page
pud_pfn() and pmd_pfn() must be avoided as those will mask away guest
physical address bits not being zero in this special case.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman