linux.git/arch, branch v4.9.61

ARM: dts: mvebu: pl310-cache disable double-linefill

2017-11-08T09:08:37+00:00

commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.

Under heavy system stress mvebu SoC using Cortex A9 sporadically
encountered instability issues.

The "double linefill" feature of L2 cache was identified as causing
dependency between read and write which lead to the deadlock.

Especially, it was the cause of deadlock seen under heavy PCIe traffic,
as this dependency violates PCIE overtaking rule.

Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration")
Signed-off-by: Yan Markman 
Signed-off-by: Igal Liberman 
Signed-off-by: Nadav Haklai 
[gregory.clement@free-electrons.com: reformulate commit log, add Armada
375 and add Fixes tag]
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

powerpc/64: Don't try to use radix MMU under a hypervisor

2017-11-08T09:08:37+00:00

[ Upstream commit 18569c1f134e1c5c88228f043c09678ae6052b7c ]

Currently, if the kernel is running on a POWER9 processor under a
hypervisor, it will try to use the radix MMU even though it doesn't have
the necessary code to use radix under a hypervisor (it doesn't negotiate
use of radix, and it doesn't do the H_REGISTER_PROC_TBL hcall). The
result is that the guest kernel will crash when it tries to turn on the
MMU.

This fixes it by looking for the /chosen/ibm,architecture-vec-5
property, and if it exists, clears the radix MMU feature bit, before we
decide whether to initialize for radix or HPT. This property is created
by the hypervisor as a result of the guest calling the
ibm,client-architecture-support method to indicate its capabilities, so
it will indicate whether the hypervisor agreed to us using radix.

Systems without a hypervisor may have this property also (for example,
skiboot creates it), so we check the HV bit in the MSR to see whether we
are running as a guest or not. If we are in hypervisor mode, then we can
do whatever we like including using the radix MMU.

The reason for using this property is that in future, when we have
support for using radix under a hypervisor, we will need to check this
property to see whether the hypervisor agreed to us using radix.

Fixes: 2bfd65e45e87 ("powerpc/mm/radix: Add radix callbacks for early init routines")
Cc: stable@vger.kernel.org # v4.7+
Signed-off-by: Paul Mackerras 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

s390/crypto: Extend key length check for AES-XTS in fips mode.

2017-11-08T09:08:37+00:00

[ Upstream commit a4f2779ecf2f42b0997fedef6fd20a931c40a3e3 ]

In fips mode only xts keys with 128 bit or 125 bit are allowed.
This fix extends the xts_aes_set_key function to check for these
valid key lengths in fips mode.

Signed-off-by: Harald Freudenberger 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

s390/prng: Adjust generation of entropy to produce real 256 bits.

2017-11-08T09:08:37+00:00

[ Upstream commit d34b1acb78af41b8b8d5c60972b6555ea19f7564 ]

The generate_entropy function used a sha256 for compacting
together 256 bits of entropy into 32 bytes hash. However, it
is questionable if a sha256 can really be used here, as
potential collisions may reduce the max entropy fitting into
a 32 byte hash value. So this batch introduces the use of
sha512 instead and the required buffer adjustments for the
calling functions.

Further more the working buffer for the generate_entropy
function has been widened from one page to two pages. So now
1024 stckf invocations are used to gather 256 bits of
entropy. This has been done to be on the save side if the
jitters of stckf values isn't as good as supposed.

Signed-off-by: Harald Freudenberger 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: 8715/1: add a private asm/unaligned.h

2017-11-08T09:08:32+00:00

commit 1cce91dfc8f7990ca3aea896bfb148f240b12860 upstream.

The asm-generic/unaligned.h header provides two different implementations
for accessing unaligned variables: the access_ok.h version used when
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers
are in fact aligned, while the le_struct.h version convinces gcc that the
alignment of a pointer is '1', to make it issue the correct load/store
instructions depending on the architecture flags.

On ARMv5 and older, we always use the second version, to let the compiler
use byte accesses. On ARMv6 and newer, we currently use the access_ok.h
version, so the compiler can use any instruction including stm/ldm and
ldrd/strd that will cause an alignment trap. This trap can significantly
impact performance when we have to do a lot of fixups and, worse, has
led to crashes in the LZ4 decompressor code that does not have a trap
handler.

This adds an ARM specific version of asm/unaligned.h that uses the
le_struct.h/be_struct.h implementation unconditionally. This should lead
to essentially the same code on ARMv6+ as before, with the exception of
using regular load/store instructions instead of the trapping instructions
multi-register variants.

The crash in the LZ4 decompressor code was probably introduced by the
patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update
LZ4 compressor module"), so linux-4.11 and higher would be affected most.
However, we probably want to have this backported to all older stable
kernels as well, to help with the performance issues.

There are two follow-ups that I think we should also work on, but not
backport to stable kernels, first to change the asm-generic version of
the header to remove the ARM special case, and second to review all
other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they
might be affected by the same problem on ARM.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: kvm: Disable branch profiling in HYP code

2017-11-08T09:08:32+00:00

commit f9b269f3098121b5d54aaf822e0898c8ed1d3fec upstream.

When HYP code runs into branch profiling code, it attempts to jump to
unmapped memory, causing a HYP Panic.

Disable the branch profiling for code designed to run at HYP mode.

Signed-off-by: Julien Thierry 
Acked-by: Marc Zyngier 
Cc: Christoffer Dall 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Russell King 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: set right LR register value for 32 bit guest when inject abort

2017-11-08T09:08:32+00:00

commit fd6c8c206fc5d0717b0433b191de0715122f33bb upstream.

When a exception is trapped to EL2, hardware uses  ELR_ELx to hold
the current fault instruction address. If KVM wants to inject a
abort to 32 bit guest, it needs to set the LR register for the
guest to emulate this abort happened in the guest. Because ARM32
architecture is pipelined execution, so the LR value has an offset to
the fault instruction address.

The offsets applied to Link value for exceptions as shown below,
which should be added for the ARM32 link register(LR).

Table taken from ARMv8 ARM DDI0487B-B, table G1-10:
Exception			Offset, for PE state of:
				A32 	  T32
Undefined Instruction 		+4 	  +2
Prefetch Abort 			+4 	  +4
Data Abort 			+8 	  +8
IRQ or FIQ 			+4 	  +4

  [ Removed unused variables in inject_abt to avoid compile warnings.
    -- Christoffer ]

Signed-off-by: Dongjiu Geng 
Tested-by: Haibin Zhang 
Reviewed-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

arm64: ensure __dump_instr() checks addr_limit

2017-11-08T09:08:32+00:00

commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.

It's possible for a user to deliberately trigger __dump_instr with a
chosen kernel address.

Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.

Where we use __dump_instr() on kernel text, we already switch to
KERNEL_DS, so this shouldn't adversely affect those cases.

Fixes: 60ffc30d5652810d ("arm64: Exception handling")
Acked-by: Will Deacon 
Signed-off-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM

2017-11-02T08:49:13+00:00

commit ac64115a66c18c01745bbd3c47a36b124e5fd8c0 upstream.

The following program causes a kernel oops:

#include 
#include 
#include 
#include 
#include 

main()
{
    int fd = open("/dev/kvm", O_RDWR);
    ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM);
}

This happens because when using the global KVM fd with
KVM_CHECK_EXTENSION, kvm_vm_ioctl_check_extension() gets
called with a NULL kvm argument, which gets dereferenced
in is_kvmppc_hv_enabled(). Spotted while reading the code.

Let's use the hv_enabled fallback variable, like everywhere
else in this function.

Fixes: 23528bb21ee2 ("KVM: PPC: Introduce KVM_CAP_PPC_HTM")
Signed-off-by: Greg Kurz 
Reviewed-by: David Gibson 
Reviewed-by: Thomas Huth 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

x86/microcode/intel: Disable late loading on model 79

2017-10-27T08:38:08+00:00

commit 723f2828a98c8ca19842042f418fb30dd8cfc0f7 upstream.

Blacklist Broadwell X model 79 for late loading due to an erratum.

Signed-off-by: Borislav Petkov 
Acked-by: Tony Luck 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20171018111225.25635-1-bp@alien8.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman