From e1d02990cd87a0d06c311fc0b12dc3839dd65e6f Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 26 Jan 2016 22:54:03 -0800 Subject: [PATCH] 3.14-stable patches added patches: arm64-clear-out-any-singlestep-state-on-a-ptrace-detach-operation.patch arm64-fix-building-without-config_uid16.patch arm64-kvm-fix-aarch32-to-aarch64-register-mapping.patch arm64-mm-ensure-that-the-zero-page-is-visible-to-the-page-table-walker.patch hid-core-avoid-uninitialized-buffer-access.patch parisc-iommu-fix-panic-due-to-trying-to-allocate-too-large-region.patch powerpc-make-cmp-xchg-and-their-atomic_-versions-fully.patch powerpc-make-value-returning-atomics-fully-ordered.patch powerpc-tm-block-signal-return-setting-invalid-msr-state.patch powerpc-tm-check-for-already-reclaimed-tasks.patch scripts-recordmcount.pl-support-data-in-text-section-on-powerpc.patch --- ...p-state-on-a-ptrace-detach-operation.patch | 39 ++++++ ...64-fix-building-without-config_uid16.patch | 62 +++++++++ ...-aarch32-to-aarch64-register-mapping.patch | 77 +++++++++++ ...-is-visible-to-the-page-table-walker.patch | 36 +++++ ...re-avoid-uninitialized-buffer-access.patch | 39 ++++++ ...-trying-to-allocate-too-large-region.patch | 127 ++++++++++++++++++ ...chg-and-their-atomic_-versions-fully.patch | 98 ++++++++++++++ ...alue-returning-atomics-fully-ordered.patch | 52 +++++++ ...nal-return-setting-invalid-msr-state.patch | 82 +++++++++++ ...tm-check-for-already-reclaimed-tasks.patch | 73 ++++++++++ ...port-data-in-text-section-on-powerpc.patch | 44 ++++++ queue-3.14/series | 11 ++ 12 files changed, 740 insertions(+) create mode 100644 queue-3.14/arm64-clear-out-any-singlestep-state-on-a-ptrace-detach-operation.patch create mode 100644 queue-3.14/arm64-fix-building-without-config_uid16.patch create mode 100644 queue-3.14/arm64-kvm-fix-aarch32-to-aarch64-register-mapping.patch create mode 100644 queue-3.14/arm64-mm-ensure-that-the-zero-page-is-visible-to-the-page-table-walker.patch create mode 100644 queue-3.14/hid-core-avoid-uninitialized-buffer-access.patch create mode 100644 queue-3.14/parisc-iommu-fix-panic-due-to-trying-to-allocate-too-large-region.patch create mode 100644 queue-3.14/powerpc-make-cmp-xchg-and-their-atomic_-versions-fully.patch create mode 100644 queue-3.14/powerpc-make-value-returning-atomics-fully-ordered.patch create mode 100644 queue-3.14/powerpc-tm-block-signal-return-setting-invalid-msr-state.patch create mode 100644 queue-3.14/powerpc-tm-check-for-already-reclaimed-tasks.patch create mode 100644 queue-3.14/scripts-recordmcount.pl-support-data-in-text-section-on-powerpc.patch diff --git a/queue-3.14/arm64-clear-out-any-singlestep-state-on-a-ptrace-detach-operation.patch b/queue-3.14/arm64-clear-out-any-singlestep-state-on-a-ptrace-detach-operation.patch new file mode 100644 index 00000000000..f057f3363a2 --- /dev/null +++ b/queue-3.14/arm64-clear-out-any-singlestep-state-on-a-ptrace-detach-operation.patch @@ -0,0 +1,39 @@ +From 5db4fd8c52810bd9740c1240ebf89223b171aa70 Mon Sep 17 00:00:00 2001 +From: John Blackwood +Date: Mon, 7 Dec 2015 11:50:34 +0000 +Subject: arm64: Clear out any singlestep state on a ptrace detach operation + +From: John Blackwood + +commit 5db4fd8c52810bd9740c1240ebf89223b171aa70 upstream. + +Make sure to clear out any ptrace singlestep state when a ptrace(2) +PTRACE_DETACH call is made on arm64 systems. + +Otherwise, the previously ptraced task will die off with a SIGTRAP +signal if the debugger just previously singlestepped the ptraced task. + +Signed-off-by: John Blackwood +[will: added comment to justify why this is in the arch code] +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/kernel/ptrace.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/arch/arm64/kernel/ptrace.c ++++ b/arch/arm64/kernel/ptrace.c +@@ -51,6 +51,12 @@ + */ + void ptrace_disable(struct task_struct *child) + { ++ /* ++ * This would be better off in core code, but PTRACE_DETACH has ++ * grown its fair share of arch-specific worts and changing it ++ * is likely to cause regressions on obscure architectures. ++ */ ++ user_disable_single_step(child); + } + + #ifdef CONFIG_HAVE_HW_BREAKPOINT diff --git a/queue-3.14/arm64-fix-building-without-config_uid16.patch b/queue-3.14/arm64-fix-building-without-config_uid16.patch new file mode 100644 index 00000000000..3afd2e77a2c --- /dev/null +++ b/queue-3.14/arm64-fix-building-without-config_uid16.patch @@ -0,0 +1,62 @@ +From fbc416ff86183e2203cdf975e2881d7c164b0271 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 20 Nov 2015 12:12:21 +0100 +Subject: arm64: fix building without CONFIG_UID16 + +From: Arnd Bergmann + +commit fbc416ff86183e2203cdf975e2881d7c164b0271 upstream. + +As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16 +disabled currently fails because the system call table still needs to +reference the individual function entry points that are provided by +kernel/sys_ni.c in this case, and the declarations are hidden inside +of #ifdef CONFIG_UID16: + +arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function) + __SYSCALL(__NR_lchown, sys_lchown16) + +I believe this problem only exists on ARM64, because older architectures +tend to not need declarations when their system call table is built +in assembly code, while newer architectures tend to not need UID16 +support. ARM64 only uses these system calls for compatibility with +32-bit ARM binaries. + +This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is +set unconditionally on ARM64 with CONFIG_COMPAT, so we see the +declarations whenever we need them, but otherwise the behavior is +unchanged. + +Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option") +Signed-off-by: Arnd Bergmann +Acked-by: Will Deacon +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/syscalls.h | 2 +- + include/linux/types.h | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/include/linux/syscalls.h ++++ b/include/linux/syscalls.h +@@ -507,7 +507,7 @@ asmlinkage long sys_chown(const char __u + asmlinkage long sys_lchown(const char __user *filename, + uid_t user, gid_t group); + asmlinkage long sys_fchown(unsigned int fd, uid_t user, gid_t group); +-#ifdef CONFIG_UID16 ++#ifdef CONFIG_HAVE_UID16 + asmlinkage long sys_chown16(const char __user *filename, + old_uid_t user, old_gid_t group); + asmlinkage long sys_lchown16(const char __user *filename, +--- a/include/linux/types.h ++++ b/include/linux/types.h +@@ -35,7 +35,7 @@ typedef __kernel_gid16_t gid16_t; + + typedef unsigned long uintptr_t; + +-#ifdef CONFIG_UID16 ++#ifdef CONFIG_HAVE_UID16 + /* This is defined by include/asm-{arch}/posix_types.h */ + typedef __kernel_old_uid_t old_uid_t; + typedef __kernel_old_gid_t old_gid_t; diff --git a/queue-3.14/arm64-kvm-fix-aarch32-to-aarch64-register-mapping.patch b/queue-3.14/arm64-kvm-fix-aarch32-to-aarch64-register-mapping.patch new file mode 100644 index 00000000000..b05d43301c1 --- /dev/null +++ b/queue-3.14/arm64-kvm-fix-aarch32-to-aarch64-register-mapping.patch @@ -0,0 +1,77 @@ +From c0f0963464c24e034b858441205455bf2a5d93ad Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Mon, 16 Nov 2015 10:28:17 +0000 +Subject: arm64: KVM: Fix AArch32 to AArch64 register mapping + +From: Marc Zyngier + +commit c0f0963464c24e034b858441205455bf2a5d93ad upstream. + +When running a 32bit guest under a 64bit hypervisor, the ARMv8 +architecture defines a mapping of the 32bit registers in the 64bit +space. This includes banked registers that are being demultiplexed +over the 64bit ones. + +On exceptions caused by an operation involving a 32bit register, the +HW exposes the register number in the ESR_EL2 register. It was so +far understood that SW had to distinguish between AArch32 and AArch64 +accesses (based on the current AArch32 mode and register number). + +It turns out that I misinterpreted the ARM ARM, and the clue is in +D1.20.1: "For some exceptions, the exception syndrome given in the +ESR_ELx identifies one or more register numbers from the issued +instruction that generated the exception. Where the exception is +taken from an Exception level using AArch32 these register numbers +give the AArch64 view of the register." + +Which means that the HW is already giving us the translated version, +and that we shouldn't try to interpret it at all (for example, doing +an MMIO operation from the IRQ mode using the LR register leads to +very unexpected behaviours). + +The fix is thus not to perform a call to vcpu_reg32() at all from +vcpu_reg(), and use whatever register number is supplied directly. +The only case we need to find out about the mapping is when we +actively generate a register access, which only occurs when injecting +a fault in a guest. + +Reviewed-by: Robin Murphy +Signed-off-by: Marc Zyngier +Signed-off-by: Christoffer Dall +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/include/asm/kvm_emulate.h | 8 +++++--- + arch/arm64/kvm/inject_fault.c | 2 +- + 2 files changed, 6 insertions(+), 4 deletions(-) + +--- a/arch/arm64/include/asm/kvm_emulate.h ++++ b/arch/arm64/include/asm/kvm_emulate.h +@@ -86,11 +86,13 @@ static inline void vcpu_set_thumb(struct + *vcpu_cpsr(vcpu) |= COMPAT_PSR_T_BIT; + } + ++/* ++ * vcpu_reg should always be passed a register number coming from a ++ * read of ESR_EL2. Otherwise, it may give the wrong result on AArch32 ++ * with banked registers. ++ */ + static inline unsigned long *vcpu_reg(const struct kvm_vcpu *vcpu, u8 reg_num) + { +- if (vcpu_mode_is_32bit(vcpu)) +- return vcpu_reg32(vcpu, reg_num); +- + return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.regs[reg_num]; + } + +--- a/arch/arm64/kvm/inject_fault.c ++++ b/arch/arm64/kvm/inject_fault.c +@@ -48,7 +48,7 @@ static void prepare_fault32(struct kvm_v + + /* Note: These now point to the banked copies */ + *vcpu_spsr(vcpu) = new_spsr_value; +- *vcpu_reg(vcpu, 14) = *vcpu_pc(vcpu) + return_offset; ++ *vcpu_reg32(vcpu, 14) = *vcpu_pc(vcpu) + return_offset; + + /* Branch to exception vector */ + if (sctlr & (1 << 13)) diff --git a/queue-3.14/arm64-mm-ensure-that-the-zero-page-is-visible-to-the-page-table-walker.patch b/queue-3.14/arm64-mm-ensure-that-the-zero-page-is-visible-to-the-page-table-walker.patch new file mode 100644 index 00000000000..c0b7aef9a6e --- /dev/null +++ b/queue-3.14/arm64-mm-ensure-that-the-zero-page-is-visible-to-the-page-table-walker.patch @@ -0,0 +1,36 @@ +From 32d6397805d00573ce1fa55f408ce2bca15b0ad3 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Thu, 10 Dec 2015 16:05:36 +0000 +Subject: arm64: mm: ensure that the zero page is visible to the page table walker + +From: Will Deacon + +commit 32d6397805d00573ce1fa55f408ce2bca15b0ad3 upstream. + +In paging_init, we allocate the zero page, memset it to zero and then +point TTBR0 to it in order to avoid speculative fetches through the +identity mapping. + +In order to guarantee that the freshly zeroed page is indeed visible to +the page table walker, we need to execute a dsb instruction prior to +writing the TTBR. + +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/mm/mmu.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/arm64/mm/mmu.c ++++ b/arch/arm64/mm/mmu.c +@@ -374,6 +374,9 @@ void __init paging_init(void) + + empty_zero_page = virt_to_page(zero_page); + ++ /* Ensure the zero page is visible to the page table walker */ ++ dsb(ishst); ++ + /* + * TTBR0 is only used for the identity mapping at this stage. Make it + * point to zero page to avoid speculatively fetching new entries. diff --git a/queue-3.14/hid-core-avoid-uninitialized-buffer-access.patch b/queue-3.14/hid-core-avoid-uninitialized-buffer-access.patch new file mode 100644 index 00000000000..6ba03da53dc --- /dev/null +++ b/queue-3.14/hid-core-avoid-uninitialized-buffer-access.patch @@ -0,0 +1,39 @@ +From 79b568b9d0c7c5d81932f4486d50b38efdd6da6d Mon Sep 17 00:00:00 2001 +From: Richard Purdie +Date: Fri, 18 Sep 2015 16:31:33 -0700 +Subject: HID: core: Avoid uninitialized buffer access + +From: Richard Purdie + +commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream. + +hid_connect adds various strings to the buffer but they're all +conditional. You can find circumstances where nothing would be written +to it but the kernel will still print the supposedly empty buffer with +printk. This leads to corruption on the console/in the logs. + +Ensure buf is initialized to an empty string. + +Signed-off-by: Richard Purdie +[dvhart: Initialize string to "" rather than assign buf[0] = NULL;] +Cc: Jiri Kosina +Cc: linux-input@vger.kernel.org +Signed-off-by: Darren Hart +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/hid-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -1506,7 +1506,7 @@ int hid_connect(struct hid_device *hdev, + "Multi-Axis Controller" + }; + const char *type, *bus; +- char buf[64]; ++ char buf[64] = ""; + unsigned int i; + int len; + int ret; diff --git a/queue-3.14/parisc-iommu-fix-panic-due-to-trying-to-allocate-too-large-region.patch b/queue-3.14/parisc-iommu-fix-panic-due-to-trying-to-allocate-too-large-region.patch new file mode 100644 index 00000000000..e35fc256178 --- /dev/null +++ b/queue-3.14/parisc-iommu-fix-panic-due-to-trying-to-allocate-too-large-region.patch @@ -0,0 +1,127 @@ +From e46e31a3696ae2d66f32c207df3969613726e636 Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Mon, 30 Nov 2015 14:47:46 -0500 +Subject: parisc iommu: fix panic due to trying to allocate too large region + +From: Mikulas Patocka + +commit e46e31a3696ae2d66f32c207df3969613726e636 upstream. + +When using the Promise TX2+ SATA controller on PA-RISC, the system often +crashes with kernel panic, for example just writing data with the dd +utility will make it crash. + +Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources + +CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2 +Backtrace: + [<000000004021497c>] show_stack+0x14/0x20 + [<0000000040410bf0>] dump_stack+0x88/0x100 + [<000000004023978c>] panic+0x124/0x360 + [<0000000040452c18>] sba_alloc_range+0x698/0x6a0 + [<0000000040453150>] sba_map_sg+0x260/0x5b8 + [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata] + [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata] + [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata] + [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130 + [<000000004049da34>] scsi_request_fn+0x6e4/0x970 + [<00000000403e95a8>] __blk_run_queue+0x40/0x60 + [<00000000403e9d8c>] blk_run_queue+0x3c/0x68 + [<000000004049a534>] scsi_run_queue+0x2a4/0x360 + [<000000004049be68>] scsi_end_request+0x1a8/0x238 + [<000000004049de84>] scsi_io_completion+0xfc/0x688 + [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0 + +The cause of the crash is not exhaustion of the IOMMU space, there is +plenty of free pages. The function sba_alloc_range is called with size +0x11000, thus the pages_needed variable is 0x11. The function +sba_search_bitmap is called with bits_wanted 0x11 and boundary size is +0x10 (because dma_get_seg_boundary(dev) returns 0xffff). + +The function sba_search_bitmap attempts to allocate 17 pages that must not +cross 16-page boundary - it can't satisfy this requirement +(iommu_is_span_boundary always returns true) and fails even if there are +many free entries in the IOMMU space. + +How did it happen that we try to allocate 17 pages that don't cross +16-page boundary? The cause is in the function iommu_coalesce_chunks. This +function tries to coalesce adjacent entries in the scatterlist. The +function does several checks if it may coalesce one entry with the next, +one of those checks is this: + + if (startsg->length + dma_len > max_seg_size) + break; + +When it finishes coalescing adjacent entries, it allocates the mapping: + +sg_dma_len(contig_sg) = dma_len; +dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE); +sg_dma_address(contig_sg) = + PIDE_FLAG + | (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT) + | dma_offset; + +It is possible that (startsg->length + dma_len > max_seg_size) is false +(we are just near the 0x10000 max_seg_size boundary), so the funcion +decides to coalesce this entry with the next entry. When the coalescing +succeeds, the function performs + dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE); +And now, because of non-zero dma_offset, dma_len is greater than 0x10000. +iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts +to allocate 17 pages for a device that must not cross 16-page boundary. + +To fix the bug, we must make sure that dma_len after addition of +dma_offset and alignment doesn't cross the segment boundary. I.e. change + if (startsg->length + dma_len > max_seg_size) + break; +to + if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size) + break; + +This patch makes this change (it precalculates max_seg_boundary at the +beginning of the function iommu_coalesce_chunks). I also added a check +that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is +not needed for Promise TX2+ SATA, but it may be needed for other devices +that have dma_get_seg_boundary lower than dma_get_max_seg_size). + +Signed-off-by: Mikulas Patocka +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/parisc/iommu-helpers.h | 15 ++++++++------- + 1 file changed, 8 insertions(+), 7 deletions(-) + +--- a/drivers/parisc/iommu-helpers.h ++++ b/drivers/parisc/iommu-helpers.h +@@ -104,7 +104,11 @@ iommu_coalesce_chunks(struct ioc *ioc, s + struct scatterlist *contig_sg; /* contig chunk head */ + unsigned long dma_offset, dma_len; /* start/len of DMA stream */ + unsigned int n_mappings = 0; +- unsigned int max_seg_size = dma_get_max_seg_size(dev); ++ unsigned int max_seg_size = min(dma_get_max_seg_size(dev), ++ (unsigned)DMA_CHUNK_SIZE); ++ unsigned int max_seg_boundary = dma_get_seg_boundary(dev) + 1; ++ if (max_seg_boundary) /* check if the addition above didn't overflow */ ++ max_seg_size = min(max_seg_size, max_seg_boundary); + + while (nents > 0) { + +@@ -139,14 +143,11 @@ iommu_coalesce_chunks(struct ioc *ioc, s + + /* + ** First make sure current dma stream won't +- ** exceed DMA_CHUNK_SIZE if we coalesce the ++ ** exceed max_seg_size if we coalesce the + ** next entry. + */ +- if(unlikely(ALIGN(dma_len + dma_offset + startsg->length, +- IOVP_SIZE) > DMA_CHUNK_SIZE)) +- break; +- +- if (startsg->length + dma_len > max_seg_size) ++ if (unlikely(ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > ++ max_seg_size)) + break; + + /* diff --git a/queue-3.14/powerpc-make-cmp-xchg-and-their-atomic_-versions-fully.patch b/queue-3.14/powerpc-make-cmp-xchg-and-their-atomic_-versions-fully.patch new file mode 100644 index 00000000000..953b7e11762 --- /dev/null +++ b/queue-3.14/powerpc-make-cmp-xchg-and-their-atomic_-versions-fully.patch @@ -0,0 +1,98 @@ +From 81d7a3294de7e9828310bbf986a67246b13fa01e Mon Sep 17 00:00:00 2001 +From: Boqun Feng +Date: Mon, 2 Nov 2015 09:30:32 +0800 +Subject: powerpc: Make {cmp}xchg* and their atomic_ versions fully + ordered + +From: Boqun Feng + +commit 81d7a3294de7e9828310bbf986a67246b13fa01e upstream. + +According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_ +versions all need to be fully ordered, however they are now just +RELEASE+ACQUIRE, which are not fully ordered. + +So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with +PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in +__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics +of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit +b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics") + +This patch depends on patch "powerpc: Make value-returning atomics fully +ordered" for PPC_ATOMIC_ENTRY_BARRIER definition. + +Signed-off-by: Boqun Feng +Reviewed-by: Paul E. McKenney +Acked-by: Peter Zijlstra (Intel) +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/arch/powerpc/include/asm/cmpxchg.h ++++ b/arch/powerpc/include/asm/cmpxchg.h +@@ -18,12 +18,12 @@ __xchg_u32(volatile void *p, unsigned lo + unsigned long prev; + + __asm__ __volatile__( +- PPC_RELEASE_BARRIER ++ PPC_ATOMIC_ENTRY_BARRIER + "1: lwarx %0,0,%2 \n" + PPC405_ERR77(0,%2) + " stwcx. %3,0,%2 \n\ + bne- 1b" +- PPC_ACQUIRE_BARRIER ++ PPC_ATOMIC_EXIT_BARRIER + : "=&r" (prev), "+m" (*(volatile unsigned int *)p) + : "r" (p), "r" (val) + : "cc", "memory"); +@@ -61,12 +61,12 @@ __xchg_u64(volatile void *p, unsigned lo + unsigned long prev; + + __asm__ __volatile__( +- PPC_RELEASE_BARRIER ++ PPC_ATOMIC_ENTRY_BARRIER + "1: ldarx %0,0,%2 \n" + PPC405_ERR77(0,%2) + " stdcx. %3,0,%2 \n\ + bne- 1b" +- PPC_ACQUIRE_BARRIER ++ PPC_ATOMIC_EXIT_BARRIER + : "=&r" (prev), "+m" (*(volatile unsigned long *)p) + : "r" (p), "r" (val) + : "cc", "memory"); +@@ -152,14 +152,14 @@ __cmpxchg_u32(volatile unsigned int *p, + unsigned int prev; + + __asm__ __volatile__ ( +- PPC_RELEASE_BARRIER ++ PPC_ATOMIC_ENTRY_BARRIER + "1: lwarx %0,0,%2 # __cmpxchg_u32\n\ + cmpw 0,%0,%3\n\ + bne- 2f\n" + PPC405_ERR77(0,%2) + " stwcx. %4,0,%2\n\ + bne- 1b" +- PPC_ACQUIRE_BARRIER ++ PPC_ATOMIC_EXIT_BARRIER + "\n\ + 2:" + : "=&r" (prev), "+m" (*p) +@@ -198,13 +198,13 @@ __cmpxchg_u64(volatile unsigned long *p, + unsigned long prev; + + __asm__ __volatile__ ( +- PPC_RELEASE_BARRIER ++ PPC_ATOMIC_ENTRY_BARRIER + "1: ldarx %0,0,%2 # __cmpxchg_u64\n\ + cmpd 0,%0,%3\n\ + bne- 2f\n\ + stdcx. %4,0,%2\n\ + bne- 1b" +- PPC_ACQUIRE_BARRIER ++ PPC_ATOMIC_EXIT_BARRIER + "\n\ + 2:" + : "=&r" (prev), "+m" (*p) diff --git a/queue-3.14/powerpc-make-value-returning-atomics-fully-ordered.patch b/queue-3.14/powerpc-make-value-returning-atomics-fully-ordered.patch new file mode 100644 index 00000000000..d6e8ec4b2ce --- /dev/null +++ b/queue-3.14/powerpc-make-value-returning-atomics-fully-ordered.patch @@ -0,0 +1,52 @@ +From 49e9cf3f0c04bf76ffa59242254110309554861d Mon Sep 17 00:00:00 2001 +From: Boqun Feng +Date: Mon, 2 Nov 2015 09:30:31 +0800 +Subject: powerpc: Make value-returning atomics fully ordered + +From: Boqun Feng + +commit 49e9cf3f0c04bf76ffa59242254110309554861d upstream. + +According to memory-barriers.txt: + +> Any atomic operation that modifies some state in memory and returns +> information about the state (old or new) implies an SMP-conditional +> general memory barrier (smp_mb()) on each side of the actual +> operation ... + +Which mean these operations should be fully ordered. However on PPC, +PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation, +which is currently "lwsync" if SMP=y. The leading "lwsync" can not +guarantee fully ordered atomics, according to Paul Mckenney: + +https://lkml.org/lkml/2015/10/14/970 + +To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee +the fully-ordered semantics. + +This also makes futex atomics fully ordered, which can avoid possible +memory ordering problems if userspace code relies on futex system call +for fully ordered semantics. + +Fixes: b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics") +Signed-off-by: Boqun Feng +Reviewed-by: Paul E. McKenney +Acked-by: Peter Zijlstra (Intel) +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/include/asm/synch.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/include/asm/synch.h ++++ b/arch/powerpc/include/asm/synch.h +@@ -44,7 +44,7 @@ static inline void isync(void) + MAKE_LWSYNC_SECTION_ENTRY(97, __lwsync_fixup); + #define PPC_ACQUIRE_BARRIER "\n" stringify_in_c(__PPC_ACQUIRE_BARRIER) + #define PPC_RELEASE_BARRIER stringify_in_c(LWSYNC) "\n" +-#define PPC_ATOMIC_ENTRY_BARRIER "\n" stringify_in_c(LWSYNC) "\n" ++#define PPC_ATOMIC_ENTRY_BARRIER "\n" stringify_in_c(sync) "\n" + #define PPC_ATOMIC_EXIT_BARRIER "\n" stringify_in_c(sync) "\n" + #else + #define PPC_ACQUIRE_BARRIER diff --git a/queue-3.14/powerpc-tm-block-signal-return-setting-invalid-msr-state.patch b/queue-3.14/powerpc-tm-block-signal-return-setting-invalid-msr-state.patch new file mode 100644 index 00000000000..6b6d3affdab --- /dev/null +++ b/queue-3.14/powerpc-tm-block-signal-return-setting-invalid-msr-state.patch @@ -0,0 +1,82 @@ +From d2b9d2a5ad5ef04ff978c9923d19730cb05efd55 Mon Sep 17 00:00:00 2001 +From: Michael Neuling +Date: Thu, 19 Nov 2015 15:44:44 +1100 +Subject: powerpc/tm: Block signal return setting invalid MSR state + +From: Michael Neuling + +commit d2b9d2a5ad5ef04ff978c9923d19730cb05efd55 upstream. + +Currently we allow both the MSR T and S bits to be set by userspace on +a signal return. Unfortunately this is a reserved configuration and +will cause a TM Bad Thing exception if attempted (via rfid). + +This patch checks for this case in both the 32 and 64 bit signals +code. If both T and S are set, we mark the context as invalid. + +Found using a syscall fuzzer. + +Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") +Signed-off-by: Michael Neuling +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/include/asm/reg.h | 1 + + arch/powerpc/kernel/signal_32.c | 14 +++++++++----- + arch/powerpc/kernel/signal_64.c | 4 ++++ + 3 files changed, 14 insertions(+), 5 deletions(-) + +--- a/arch/powerpc/include/asm/reg.h ++++ b/arch/powerpc/include/asm/reg.h +@@ -108,6 +108,7 @@ + #define MSR_TS_T __MASK(MSR_TS_T_LG) /* Transaction Transactional */ + #define MSR_TS_MASK (MSR_TS_T | MSR_TS_S) /* Transaction State bits */ + #define MSR_TM_ACTIVE(x) (((x) & MSR_TS_MASK) != 0) /* Transaction active? */ ++#define MSR_TM_RESV(x) (((x) & MSR_TS_MASK) == MSR_TS_MASK) /* Reserved */ + #define MSR_TM_TRANSACTIONAL(x) (((x) & MSR_TS_MASK) == MSR_TS_T) + #define MSR_TM_SUSPENDED(x) (((x) & MSR_TS_MASK) == MSR_TS_S) + +--- a/arch/powerpc/kernel/signal_32.c ++++ b/arch/powerpc/kernel/signal_32.c +@@ -876,6 +876,15 @@ static long restore_tm_user_regs(struct + return 1; + #endif /* CONFIG_SPE */ + ++ /* Get the top half of the MSR from the user context */ ++ if (__get_user(msr_hi, &tm_sr->mc_gregs[PT_MSR])) ++ return 1; ++ msr_hi <<= 32; ++ /* If TM bits are set to the reserved value, it's an invalid context */ ++ if (MSR_TM_RESV(msr_hi)) ++ return 1; ++ /* Pull in the MSR TM bits from the user context */ ++ regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr_hi & MSR_TS_MASK); + /* Now, recheckpoint. This loads up all of the checkpointed (older) + * registers, including FP and V[S]Rs. After recheckpointing, the + * transactional versions should be loaded. +@@ -885,11 +894,6 @@ static long restore_tm_user_regs(struct + current->thread.tm_texasr |= TEXASR_FS; + /* This loads the checkpointed FP/VEC state, if used */ + tm_recheckpoint(¤t->thread, msr); +- /* Get the top half of the MSR */ +- if (__get_user(msr_hi, &tm_sr->mc_gregs[PT_MSR])) +- return 1; +- /* Pull in MSR TM from user context */ +- regs->msr = (regs->msr & ~MSR_TS_MASK) | ((msr_hi<<32) & MSR_TS_MASK); + + /* This loads the speculative FP/VEC state, if used */ + if (msr & MSR_FP) { +--- a/arch/powerpc/kernel/signal_64.c ++++ b/arch/powerpc/kernel/signal_64.c +@@ -428,6 +428,10 @@ static long restore_tm_sigcontexts(struc + + /* get MSR separately, transfer the LE bit if doing signal return */ + err |= __get_user(msr, &sc->gp_regs[PT_MSR]); ++ /* Don't allow reserved mode. */ ++ if (MSR_TM_RESV(msr)) ++ return -EINVAL; ++ + /* pull in MSR TM from user context */ + regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK); + diff --git a/queue-3.14/powerpc-tm-check-for-already-reclaimed-tasks.patch b/queue-3.14/powerpc-tm-check-for-already-reclaimed-tasks.patch new file mode 100644 index 00000000000..ecc5d682113 --- /dev/null +++ b/queue-3.14/powerpc-tm-check-for-already-reclaimed-tasks.patch @@ -0,0 +1,73 @@ +From 7f821fc9c77a9b01fe7b1d6e72717b33d8d64142 Mon Sep 17 00:00:00 2001 +From: Michael Neuling +Date: Thu, 19 Nov 2015 15:44:45 +1100 +Subject: powerpc/tm: Check for already reclaimed tasks + +From: Michael Neuling + +commit 7f821fc9c77a9b01fe7b1d6e72717b33d8d64142 upstream. + +Currently we can hit a scenario where we'll tm_reclaim() twice. This +results in a TM bad thing exception because the second reclaim occurs +when not in suspend mode. + +The scenario in which this can happen is the following. We attempt to +deliver a signal to userspace. To do this we need obtain the stack +pointer to write the signal context. To get this stack pointer we +must tm_reclaim() in case we need to use the checkpointed stack +pointer (see get_tm_stackpointer()). Normally we'd then return +directly to userspace to deliver the signal without going through +__switch_to(). + +Unfortunatley, if at this point we get an error (such as a bad +userspace stack pointer), we need to exit the process. The exit will +result in a __switch_to(). __switch_to() will attempt to save the +process state which results in another tm_reclaim(). This +tm_reclaim() now causes a TM Bad Thing exception as this state has +already been saved and the processor is no longer in TM suspend mode. +Whee! + +This patch checks the state of the MSR to ensure we are TM suspended +before we attempt the tm_reclaim(). If we've already saved the state +away, we should no longer be in TM suspend mode. This has the +additional advantage of checking for a potential TM Bad Thing +exception. + +Found using syscall fuzzer. + +Fixes: fb09692e71f1 ("powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes") +Signed-off-by: Michael Neuling +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/process.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +--- a/arch/powerpc/kernel/process.c ++++ b/arch/powerpc/kernel/process.c +@@ -545,6 +545,24 @@ static void tm_reclaim_thread(struct thr + msr_diff &= MSR_FP | MSR_VEC | MSR_VSX | MSR_FE0 | MSR_FE1; + } + ++ /* ++ * Use the current MSR TM suspended bit to track if we have ++ * checkpointed state outstanding. ++ * On signal delivery, we'd normally reclaim the checkpointed ++ * state to obtain stack pointer (see:get_tm_stackpointer()). ++ * This will then directly return to userspace without going ++ * through __switch_to(). However, if the stack frame is bad, ++ * we need to exit this thread which calls __switch_to() which ++ * will again attempt to reclaim the already saved tm state. ++ * Hence we need to check that we've not already reclaimed ++ * this state. ++ * We do this using the current MSR, rather tracking it in ++ * some specific thread_struct bit, as it has the additional ++ * benifit of checking for a potential TM bad thing exception. ++ */ ++ if (!MSR_TM_SUSPENDED(mfmsr())) ++ return; ++ + tm_reclaim(thr, thr->regs->msr, cause); + + /* Having done the reclaim, we now have the checkpointed diff --git a/queue-3.14/scripts-recordmcount.pl-support-data-in-text-section-on-powerpc.patch b/queue-3.14/scripts-recordmcount.pl-support-data-in-text-section-on-powerpc.patch new file mode 100644 index 00000000000..1efde7d4581 --- /dev/null +++ b/queue-3.14/scripts-recordmcount.pl-support-data-in-text-section-on-powerpc.patch @@ -0,0 +1,44 @@ +From 2e50c4bef77511b42cc226865d6bc568fa7f8769 Mon Sep 17 00:00:00 2001 +From: Ulrich Weigand +Date: Tue, 12 Jan 2016 23:14:22 +1100 +Subject: scripts/recordmcount.pl: support data in text section on powerpc + +From: Ulrich Weigand + +commit 2e50c4bef77511b42cc226865d6bc568fa7f8769 upstream. + +If a text section starts out with a data blob before the first +function start label, disassembly parsing doing in recordmcount.pl +gets confused on powerpc, leading to creation of corrupted module +objects. + +This was not a problem so far since the compiler would never create +such text sections. However, this has changed with a recent change +in GCC 6 to support distances of > 2GB between a function and its +assoicated TOC in the ELFv2 ABI, exposing this problem. + +There is already code in recordmcount.pl to handle such data blobs +on the sparc64 platform. This patch uses the same method to handle +those on powerpc as well. + +Acked-by: Steven Rostedt +Signed-off-by: Ulrich Weigand +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + scripts/recordmcount.pl | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/scripts/recordmcount.pl ++++ b/scripts/recordmcount.pl +@@ -265,7 +265,8 @@ if ($arch eq "x86_64") { + + } elsif ($arch eq "powerpc") { + $local_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\.?\\S+)"; +- $function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?.*?)>:"; ++ # See comment in the sparc64 section for why we use '\w'. ++ $function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?\\w*?)>:"; + $mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s\\.?_mcount\$"; + + if ($bits == 64) { diff --git a/queue-3.14/series b/queue-3.14/series index 307bd3c876c..f79f397038d 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -44,3 +44,14 @@ ipv6-update-skb-csum-when-ce-mark-is-propagated.patch isdn_ppp-add-checks-for-allocation-failure-in-isdn_ppp_open.patch ppp-slip-validate-vj-compression-slot-parameters-completely.patch team-replace-rcu_read_lock-with-a-mutex-in-team_vlan_rx_kill_vid.patch +powerpc-tm-block-signal-return-setting-invalid-msr-state.patch +powerpc-tm-check-for-already-reclaimed-tasks.patch +powerpc-make-value-returning-atomics-fully-ordered.patch +powerpc-make-cmp-xchg-and-their-atomic_-versions-fully.patch +scripts-recordmcount.pl-support-data-in-text-section-on-powerpc.patch +arm64-kvm-fix-aarch32-to-aarch64-register-mapping.patch +arm64-fix-building-without-config_uid16.patch +arm64-clear-out-any-singlestep-state-on-a-ptrace-detach-operation.patch +arm64-mm-ensure-that-the-zero-page-is-visible-to-the-page-table-walker.patch +parisc-iommu-fix-panic-due-to-trying-to-allocate-too-large-region.patch +hid-core-avoid-uninitialized-buffer-access.patch -- 2.47.3