BMC/Intel-BMC/linux.git/arch, branch v4.4.28

powerpc/mm: Prevent unlikely crash in copro_calculate_slb()

2016-10-28T07:01:35+00:00

commit d2cf909cda5f8c5609cb7ed6cda816c3e15528c7 upstream. If a cxl adapter faults on an invalid address for a kernel context, we may enter copro_calculate_slb() with a NULL mm pointer (kernel context) and an effective address which looks like a user address. Which will cause a crash when dereferencing mm. It is clearly an AFU bug, but there's no reason to crash either. So return an error, so that cxl can ack the interrupt with an address error. Fixes: 73d16a6e0e51 ("powerpc/cell: Move data segment faulting code out of cell platform") Signed-off-by: Frederic Barrat Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

arm64: kernel: Init MDCR_EL2 even in the absence of a PMU

2016-10-28T07:01:35+00:00

commit 850540351bb1a4fa5f192e5ce55b89928cc57f42 upstream. Commit f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") made sure we wouldn't access unimplemented PMU registers, but also left MDCR_EL2 uninitialized in that case, leading to trap bits being potentially left set. Make sure we always write something in that register. Fixes: f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") Cc: Lorenzo Pieralisi Cc: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

arm64: percpu: rewrite ll/sc loops in assembly

2016-10-28T07:01:35+00:00

commit 1e6e57d9b34a9075d5f9e2048ea7b09756590d11 upstream. Writing the outer loop of an LL/SC sequence using do {...} while constructs potentially allows the compiler to hoist memory accesses between the STXR and the branch back to the LDXR. On CPUs that do not guarantee forward progress of LL/SC loops when faced with memory accesses to the same ERG (up to 2k) between the failed STXR and the branch back, we may end up livelocking. This patch avoids this issue in our percpu atomics by rewriting the outer loop as part of the LL/SC inline assembly block. Fixes: f97fc810798c ("arm64: percpu: Implement this_cpu operations") Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

s390/mm: fix gmap tlb flush issues

2016-10-28T07:01:34+00:00

commit f045402984404ddc11016358411e445192919047 upstream. __tlb_flush_asce() should never be used if multiple asce belong to a mm. As this function changes mm logic determining if local or global tlb flushes will be neded, we might end up flushing only the gmap asce on all CPUs and a follow up mm asce flushes will only flush on the local CPU, although that asce ran on multiple CPUs. The missing tlb flushes will provoke strange faults in user space and even low address protections in user space, crashing the kernel. Fixes: 1b948d6caec4 ("s390/mm,tlb: optimize TLB flushing for zEC12") Cc: stable@vger.kernel.org # 3.15+ Reported-by: Sascha Silbe Acked-by: Martin Schwidefsky Signed-off-by: David Hildenbrand Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman

kvm: x86: memset whole irq_eoi

2016-10-28T07:01:33+00:00

commit 8678654e3c7ad7b0f4beb03fa89691279cba71f9 upstream. gcc 7 warns: arch/x86/kvm/ioapic.c: In function 'kvm_ioapic_reset': arch/x86/kvm/ioapic.c:597:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] And it is right. Memset whole array using sizeof operator. Signed-off-by: Jiri Slaby Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Cc: x86@kernel.org Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Paolo Bonzini [Added x86 subject tag] Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman

x86/e820: Don't merge consecutive E820_PRAM ranges

2016-10-28T07:01:33+00:00

commit 23446cb66c073b827779e5eb3dec301623299b32 upstream. Commit: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") ... fixed up the broken manipulations of max_pfn in the presence of E820_PRAM ranges. However, it also broke the sanitize_e820_map() support for not merging E820_PRAM ranges. Re-introduce the enabling to keep resource boundaries between consecutive defined ranges. Otherwise, for example, an environment that boots with memmap=2G!8G,2G!10G will end up with a single 4G /dev/pmem0 device instead of a /dev/pmem0 and /dev/pmem1 device 2G in size. Reported-by: Dave Chinner Signed-off-by: Dan Williams Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jeff Moyer Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhang Yi Cc: linux-nvdimm@lists.01.org Fixes: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") Link: http://lkml.kernel.org/r/147629530854.10618.10383744751594021268.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

arc: don't leak bits of kernel stack into coredump

2016-10-28T07:01:32+00:00

commit 7798bf2140ebcc36eafec6a4194fffd8d585d471 upstream. On faulting sigreturn we do get SIGSEGV, all right, but anything we'd put into pt_regs could end up in the coredump. And since __copy_from_user() never zeroed on arc, we'd better bugger off on its failure without copying random uninitialized bits of kernel stack into pt_regs... Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

metag: Only define atomic_dec_if_positive conditionally

2016-10-28T07:01:31+00:00

commit 35d04077ad96ed33ceea2501f5a4f1eacda77218 upstream. The definition of atomic_dec_if_positive() assumes that atomic_sub_if_positive() exists, which is only the case if metag specific atomics are used. This results in the following build error when trying to build metag1_defconfig. kernel/ucount.c: In function 'dec_ucount': kernel/ucount.c:211: error: implicit declaration of function 'atomic_sub_if_positive' Moving the definition of atomic_dec_if_positive() into the metag conditional code fixes the problem. Fixes: 6006c0d8ce94 ("metag: Atomics, locks and bitops") Signed-off-by: Guenter Roeck Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman

MIPS: ptrace: Fix regs_return_value for kernel context

2016-10-28T07:01:30+00:00

commit 74f1077b5b783e7bf4fa3007cefdc8dbd6c07518 upstream. Currently regs_return_value always negates reg[2] if it determines the syscall has failed, but when called in kernel context this check is invalid and may result in returning a wrong value. This fixes errors reported by CONFIG_KPROBES_SANITY_TEST Fixes: d7e7528bcd45 ("Audit: push audit success and retcode into arch ptrace.h") Signed-off-by: Marcin Nowakowski Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14381/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

MIPS: Fix -mabi=64 build of vdso.lds

2016-10-28T07:01:30+00:00

commit 034827c727f7f3946a18355b63995b402c226c82 upstream. The native ABI vDSO linker script vdso.lds is built by preprocessing vdso.lds.S, with the native -mabi flag passed in to get the correct ABI definitions. Unfortunately however certain toolchains choke on -mabi=64 without a corresponding compatible -march flag, for example: cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds, which includes the appropriate -march flag. Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: James Hogan Reviewed-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14368/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman