November 2017 - Linux-stable-mirror

[Linux-stable-mirror] Patch "powerpc/signal: Properly handle return value from uprobe_deny_signal()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/signal: Properly handle return value from uprobe_deny_signal() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 46725b17f1c6c815a41429259b3f070c01e71bc1 Mon Sep 17 00:00:00 2001 From: "Naveen N. Rao" <naveen.n.rao(a)linux.vnet.ibm.com> Date: Thu, 31 Aug 2017 21:55:57 +0530 Subject: powerpc/signal: Properly handle return value from uprobe_deny_signal() From: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> commit 46725b17f1c6c815a41429259b3f070c01e71bc1 upstream. When a uprobe is installed on an instruction that we currently do not emulate, we copy the instruction into a xol buffer and single step that instruction. If that instruction generates a fault, we abort the single stepping before invoking the signal handler. Once the signal handler is done, the uprobe trap is hit again since the instruction is retried and the process repeats. We use uprobe_deny_signal() to detect if the xol instruction triggered a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the signal is not handled until after the single stepping is aborted. In this case, uprobe_deny_signal() returns true and get_signal() ends up returning 0. However, in do_signal(), we are not looking at the return value, but depending on ksig.sig for further action, all with an uninitialized ksig that is not touched in this scenario. Fix the same by initializing ksig.sig to 0. Fixes: 129b69df9c90 ("powerpc: Use get_signal() signal_setup_done()") Reported-by: Anton Blanchard <anton(a)samba.org> Signed-off-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/signal.c +++ b/arch/powerpc/kernel/signal.c @@ -103,7 +103,7 @@ static void check_syscall_restart(struct static void do_signal(struct task_struct *tsk) { sigset_t *oldset = sigmask_to_save(); - struct ksignal ksig; + struct ksignal ksig = { .sig = 0 }; int ret; int is32 = is_32bit_task(); Patches currently in stable-queue which might be from naveen.n.rao(a)linux.vnet.ibm.com are queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/mm/radix: Fix crashes on Power9 DD1 with radix MMU and STRICT_RWX" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/mm/radix: Fix crashes on Power9 DD1 with radix MMU and STRICT_RWX to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f79ad50ea3c73fb1ea5b09e95c864e5bb263adfb Mon Sep 17 00:00:00 2001 From: Balbir Singh <bsingharora(a)gmail.com> Date: Mon, 16 Oct 2017 16:21:35 +1100 Subject: powerpc/mm/radix: Fix crashes on Power9 DD1 with radix MMU and STRICT_RWX From: Balbir Singh <bsingharora(a)gmail.com> commit f79ad50ea3c73fb1ea5b09e95c864e5bb263adfb upstream. When using the radix MMU on Power9 DD1, to work around a hardware problem, radix__pte_update() is required to do a two stage update of the PTE. First we write a zero value into the PTE, then we flush the TLB, and then we write the new PTE value. In the normal case that works OK, but it does not work if we're updating the PTE that maps the code we're executing, because the mapping is removed by the TLB flush and we can no longer execute from it. Unfortunately the STRICT_RWX code needs to do exactly that. The exact symptoms when we hit this case vary, sometimes we print an oops and then get stuck after that, but I've also seen a machine just get stuck continually page faulting with no oops printed. The variance is presumably due to the exact layout of the text and the page size used for the mappings. In all cases we are unable to boot to a shell. There are possible solutions such as creating a second mapping of the TLB flush code, executing from that, and then jumping back to the original. However we don't want to add that level of complexity for a DD1 work around. So just detect that we're running on Power9 DD1 and refrain from changing the permissions, effectively disabling STRICT_RWX on Power9 DD1. Fixes: 7614ff3272a1 ("powerpc/mm/radix: Implement STRICT_RWX/mark_rodata_ro() for Radix") Reported-by: Andrew Jeffery <andrew(a)aj.id.au> [Changelog as suggested by Michael Ellerman <mpe(a)ellerman.id.au>] Signed-off-by: Balbir Singh <bsingharora(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/pgtable-radix.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/arch/powerpc/mm/pgtable-radix.c +++ b/arch/powerpc/mm/pgtable-radix.c @@ -169,6 +169,16 @@ void radix__mark_rodata_ro(void) { unsigned long start, end; + /* + * mark_rodata_ro() will mark itself as !writable at some point. + * Due to DD1 workaround in radix__pte_update(), we'll end up with + * an invalid pte and the system will crash quite severly. + */ + if (cpu_has_feature(CPU_FTR_POWER9_DD1)) { + pr_warn("Warning: Unable to mark rodata read only on P9 DD1\n"); + return; + } + start = (unsigned long)_stext; end = (unsigned long)__init_begin; Patches currently in stable-queue which might be from bsingharora(a)gmail.com are queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/perf/imc: Use cpu_to_node() not topology_physical_package_id()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/perf/imc: Use cpu_to_node() not topology_physical_package_id() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f3f1dfd600ff82b18b7ea73d80eb27f476a6aa97 Mon Sep 17 00:00:00 2001 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 16 Oct 2017 00:13:41 +0530 Subject: powerpc/perf/imc: Use cpu_to_node() not topology_physical_package_id() From: Michael Ellerman <mpe(a)ellerman.id.au> commit f3f1dfd600ff82b18b7ea73d80eb27f476a6aa97 upstream. init_imc_pmu() uses topology_physical_package_id() to detect the node id of the processor it is on to get local memory, but that's wrong, and can lead to crashes. Fix it to use cpu_to_node(). Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support") Reported-By: Rob Lippert <rlippert(a)google.com> Tested-By: Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/perf/imc-pmu.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/powerpc/perf/imc-pmu.c +++ b/arch/powerpc/perf/imc-pmu.c @@ -467,7 +467,7 @@ static int nest_imc_event_init(struct pe * Nest HW counter memory resides in a per-chip reserve-memory (HOMER). * Get the base memory addresss for this cpu. */ - chip_id = topology_physical_package_id(event->cpu); + chip_id = cpu_to_chip_id(event->cpu); pcni = pmu->mem_info; do { if (pcni->id == chip_id) { @@ -524,19 +524,19 @@ static int nest_imc_event_init(struct pe */ static int core_imc_mem_init(int cpu, int size) { - int phys_id, rc = 0, core_id = (cpu / threads_per_core); + int nid, rc = 0, core_id = (cpu / threads_per_core); struct imc_mem_info *mem_info; /* * alloc_pages_node() will allocate memory for core in the * local node only. */ - phys_id = topology_physical_package_id(cpu); + nid = cpu_to_node(cpu); mem_info = &core_imc_pmu->mem_info[core_id]; mem_info->id = core_id; /* We need only vbase for core counters */ - mem_info->vbase = page_address(alloc_pages_node(phys_id, + mem_info->vbase = page_address(alloc_pages_node(nid, GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE | __GFP_NOWARN, get_order(size))); if (!mem_info->vbase) @@ -797,14 +797,14 @@ static int core_imc_event_init(struct pe static int thread_imc_mem_alloc(int cpu_id, int size) { u64 ldbar_value, *local_mem = per_cpu(thread_imc_mem, cpu_id); - int phys_id = topology_physical_package_id(cpu_id); + int nid = cpu_to_node(cpu_id); if (!local_mem) { /* * This case could happen only once at start, since we dont * free the memory in cpu offline path. */ - local_mem = page_address(alloc_pages_node(phys_id, + local_mem = page_address(alloc_pages_node(nid, GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE | __GFP_NOWARN, get_order(size))); if (!local_mem) Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.14/powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch queue-4.14/powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc: Fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc: Fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 252eb55816a6f69ef9464cad303cdb3326cdc61d Mon Sep 17 00:00:00 2001 From: Christophe Leroy <christophe.leroy(a)c-s.fr> Date: Tue, 21 Nov 2017 15:28:20 +0100 Subject: powerpc: Fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX From: Christophe Leroy <christophe.leroy(a)c-s.fr> commit 252eb55816a6f69ef9464cad303cdb3326cdc61d upstream. On powerpc32, patch_instruction() is called by apply_feature_fixups() which is called from early_init() There is the following note in front of early_init(): * Note that the kernel may be running at an address which is different * from the address that it was linked at, so we must use RELOC/PTRRELOC * to access static data (including strings). -- paulus Therefore, slab_is_available() cannot be called yet, and text_poke_area must be addressed with PTRRELOC() Fixes: 95902e6c8864 ("powerpc/mm: Implement STRICT_KERNEL_RWX on PPC32") Reported-by: Meelis Roos <mroos(a)linux.ee> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/lib/code-patching.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/arch/powerpc/lib/code-patching.c +++ b/arch/powerpc/lib/code-patching.c @@ -21,6 +21,7 @@ #include <asm/tlbflush.h> #include <asm/page.h> #include <asm/code-patching.h> +#include <asm/setup.h> static int __patch_instruction(unsigned int *addr, unsigned int instr) { @@ -146,11 +147,8 @@ int patch_instruction(unsigned int *addr * During early early boot patch_instruction is called * when text_poke_area is not ready, but we still need * to allow patching. We just do the plain old patching - * We use slab_is_available and per cpu read * via this_cpu_read - * of text_poke_area. Per-CPU areas might not be up early - * this can create problems with just using this_cpu_read() */ - if (!slab_is_available() || !this_cpu_read(text_poke_area)) + if (!this_cpu_read(*PTRRELOC(&text_poke_area))) return __patch_instruction(addr, instr); local_irq_save(flags); Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 85e3f1adcb9d49300b0a943bb93f9604be375bfb Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:39 +1100 Subject: powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation From: Nicholas Piggin <npiggin(a)gmail.com> commit 85e3f1adcb9d49300b0a943bb93f9604be375bfb upstream. Radix VA space allocations test addresses against mm->task_size which is 512TB, even in cases where the intention is to limit allocation to below 128TB. This results in mmap with a hint address below 128TB but address + length above 128TB succeeding when it should fail (as hash does after the previous patch). Set the high address limit to be considered up front, and base subsequent allocation checks on that consistently. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/hugetlbpage-radix.c | 26 +++++++++++------ arch/powerpc/mm/mmap.c | 55 +++++++++++++++++++++--------------- 2 files changed, 50 insertions(+), 31 deletions(-) --- a/arch/powerpc/mm/hugetlbpage-radix.c +++ b/arch/powerpc/mm/hugetlbpage-radix.c @@ -49,17 +49,28 @@ radix__hugetlb_get_unmapped_area(struct struct mm_struct *mm = current->mm; struct vm_area_struct *vma; struct hstate *h = hstate_file(file); + int fixed = (flags & MAP_FIXED); + unsigned long high_limit; struct vm_unmapped_area_info info; - if (unlikely(addr > mm->context.addr_limit && addr < TASK_SIZE)) - mm->context.addr_limit = TASK_SIZE; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit || (fixed && (addr + len > high_limit))) + high_limit = TASK_SIZE; if (len & ~huge_page_mask(h)) return -EINVAL; - if (len > mm->task_size) + if (len > high_limit) return -ENOMEM; + if (fixed) { + if (addr > high_limit - len) + return -ENOMEM; + } - if (flags & MAP_FIXED) { + if (unlikely(addr > mm->context.addr_limit && + mm->context.addr_limit != TASK_SIZE)) + mm->context.addr_limit = TASK_SIZE; + + if (fixed) { if (prepare_hugepage_range(file, addr, len)) return -EINVAL; return addr; @@ -68,7 +79,7 @@ radix__hugetlb_get_unmapped_area(struct if (addr) { addr = ALIGN(addr, huge_page_size(h)); vma = find_vma(mm, addr); - if (mm->task_size - len >= addr && + if (high_limit - len >= addr && (!vma || addr + len <= vm_start_gap(vma))) return addr; } @@ -79,12 +90,9 @@ radix__hugetlb_get_unmapped_area(struct info.flags = VM_UNMAPPED_AREA_TOPDOWN; info.length = len; info.low_limit = PAGE_SIZE; - info.high_limit = current->mm->mmap_base; + info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; - if (addr > DEFAULT_MAP_WINDOW) - info.high_limit += mm->context.addr_limit - DEFAULT_MAP_WINDOW; - return vm_unmapped_area(&info); } --- a/arch/powerpc/mm/mmap.c +++ b/arch/powerpc/mm/mmap.c @@ -106,22 +106,32 @@ radix__arch_get_unmapped_area(struct fil { struct mm_struct *mm = current->mm; struct vm_area_struct *vma; + int fixed = (flags & MAP_FIXED); + unsigned long high_limit; struct vm_unmapped_area_info info; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit || (fixed && (addr + len > high_limit))) + high_limit = TASK_SIZE; + + if (len > high_limit) + return -ENOMEM; + if (fixed) { + if (addr > high_limit - len) + return -ENOMEM; + } + if (unlikely(addr > mm->context.addr_limit && mm->context.addr_limit != TASK_SIZE)) mm->context.addr_limit = TASK_SIZE; - if (len > mm->task_size - mmap_min_addr) - return -ENOMEM; - - if (flags & MAP_FIXED) + if (fixed) return addr; if (addr) { addr = PAGE_ALIGN(addr); vma = find_vma(mm, addr); - if (mm->task_size - len >= addr && addr >= mmap_min_addr && + if (high_limit - len >= addr && addr >= mmap_min_addr && (!vma || addr + len <= vm_start_gap(vma))) return addr; } @@ -129,13 +139,9 @@ radix__arch_get_unmapped_area(struct fil info.flags = 0; info.length = len; info.low_limit = mm->mmap_base; + info.high_limit = high_limit; info.align_mask = 0; - if (unlikely(addr > DEFAULT_MAP_WINDOW)) - info.high_limit = mm->context.addr_limit; - else - info.high_limit = DEFAULT_MAP_WINDOW; - return vm_unmapped_area(&info); } @@ -149,37 +155,42 @@ radix__arch_get_unmapped_area_topdown(st struct vm_area_struct *vma; struct mm_struct *mm = current->mm; unsigned long addr = addr0; + int fixed = (flags & MAP_FIXED); + unsigned long high_limit; struct vm_unmapped_area_info info; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit || (fixed && (addr + len > high_limit))) + high_limit = TASK_SIZE; + + if (len > high_limit) + return -ENOMEM; + if (fixed) { + if (addr > high_limit - len) + return -ENOMEM; + } + if (unlikely(addr > mm->context.addr_limit && mm->context.addr_limit != TASK_SIZE)) mm->context.addr_limit = TASK_SIZE; - /* requested length too big for entire address space */ - if (len > mm->task_size - mmap_min_addr) - return -ENOMEM; - - if (flags & MAP_FIXED) + if (fixed) return addr; - /* requesting a specific address */ if (addr) { addr = PAGE_ALIGN(addr); vma = find_vma(mm, addr); - if (mm->task_size - len >= addr && addr >= mmap_min_addr && - (!vma || addr + len <= vm_start_gap(vma))) + if (high_limit - len >= addr && addr >= mmap_min_addr && + (!vma || addr + len <= vm_start_gap(vma))) return addr; } info.flags = VM_UNMAPPED_AREA_TOPDOWN; info.length = len; info.low_limit = max(PAGE_SIZE, mmap_min_addr); - info.high_limit = mm->mmap_base; + info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW); info.align_mask = 0; - if (addr > DEFAULT_MAP_WINDOW) - info.high_limit += mm->context.addr_limit - DEFAULT_MAP_WINDOW; - addr = vm_unmapped_area(&info); if (!(addr & ~PAGE_MASK)) return addr; Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Fix 512T hint detection to use >= 128T" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/64s/hash: Fix 512T hint detection to use >= 128T to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ece370996b694ae263025e056ad785afc1be5ab Mon Sep 17 00:00:00 2001 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 13 Nov 2017 23:17:28 +1100 Subject: powerpc/64s/hash: Fix 512T hint detection to use >= 128T From: Michael Ellerman <mpe(a)ellerman.id.au> commit 7ece370996b694ae263025e056ad785afc1be5ab upstream. Currently userspace is able to request mmap() search between 128T-512T by specifying a hint address that is greater than 128T. But that means a hint of 128T exactly will return an address below 128T, which is confusing and wrong. So fix the logic to check the hint is greater than *or equal* to 128T. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Suggested-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Suggested-by: Nicholas Piggin <npiggin(a)gmail.com> [mpe: Split out of Nick's bigger patch] Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/slice.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -419,7 +419,7 @@ unsigned long slice_get_unmapped_area(un /* * Check if we need to expland slice area. */ - if (unlikely(addr > mm->context.addr_limit && + if (unlikely(addr >= mm->context.addr_limit && mm->context.addr_limit != TASK_SIZE)) { mm->context.addr_limit = TASK_SIZE; on_each_cpu(slice_flush_segments, mm, 1); @@ -427,7 +427,7 @@ unsigned long slice_get_unmapped_area(un /* * This mmap request can allocate upt to 512TB */ - if (addr > DEFAULT_MAP_WINDOW) + if (addr >= DEFAULT_MAP_WINDOW) high_limit = mm->context.addr_limit; else high_limit = DEFAULT_MAP_WINDOW; Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.14/powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch queue-4.14/powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6a72dc038b615229a1b285829d6c8378d15c2347 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:36 +1100 Subject: powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation From: Nicholas Piggin <npiggin(a)gmail.com> commit 6a72dc038b615229a1b285829d6c8378d15c2347 upstream. When allocating VA space with a hint that crosses 128TB, the SLB addr_limit variable is not expanded if addr is not > 128TB, but the slice allocation looks at task_size, which is 512TB. This results in slice_check_fit() incorrectly succeeding because the slice_count truncates off bit 128 of the requested mask, so the comparison to the available mask succeeds. Fix this by using mm->context.addr_limit instead of mm->task_size for testing allocation limits. This causes such allocations to fail. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Reported-by: Florian Weimer <fweimer(a)redhat.com> Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/slice.c | 50 +++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 26 deletions(-) --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -96,7 +96,7 @@ static int slice_area_is_free(struct mm_ { struct vm_area_struct *vma; - if ((mm->task_size - len) < addr) + if ((mm->context.addr_limit - len) < addr) return 0; vma = find_vma(mm, addr); return (!vma || (addr + len) <= vm_start_gap(vma)); @@ -133,7 +133,7 @@ static void slice_mask_for_free(struct m if (!slice_low_has_vma(mm, i)) ret->low_slices |= 1u << i; - if (mm->task_size <= SLICE_LOW_TOP) + if (mm->context.addr_limit <= SLICE_LOW_TOP) return; for (i = 0; i < GET_HIGH_SLICE_INDEX(mm->context.addr_limit); i++) @@ -412,25 +412,31 @@ unsigned long slice_get_unmapped_area(un struct slice_mask compat_mask; int fixed = (flags & MAP_FIXED); int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT); + unsigned long page_size = 1UL << pshift; struct mm_struct *mm = current->mm; unsigned long newaddr; unsigned long high_limit; - /* - * Check if we need to expland slice area. - */ - if (unlikely(addr >= mm->context.addr_limit && - mm->context.addr_limit != TASK_SIZE)) { - mm->context.addr_limit = TASK_SIZE; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit) + high_limit = TASK_SIZE; + + if (len > high_limit) + return -ENOMEM; + if (len & (page_size - 1)) + return -EINVAL; + if (fixed) { + if (addr & (page_size - 1)) + return -EINVAL; + if (addr > high_limit - len) + return -ENOMEM; + } + + if (high_limit > mm->context.addr_limit) { + mm->context.addr_limit = high_limit; on_each_cpu(slice_flush_segments, mm, 1); } - /* - * This mmap request can allocate upt to 512TB - */ - if (addr >= DEFAULT_MAP_WINDOW) - high_limit = mm->context.addr_limit; - else - high_limit = DEFAULT_MAP_WINDOW; + /* * init different masks */ @@ -446,27 +452,19 @@ unsigned long slice_get_unmapped_area(un /* Sanity checks */ BUG_ON(mm->task_size == 0); + BUG_ON(mm->context.addr_limit == 0); VM_BUG_ON(radix_enabled()); slice_dbg("slice_get_unmapped_area(mm=%p, psize=%d...\n", mm, psize); slice_dbg(" addr=%lx, len=%lx, flags=%lx, topdown=%d\n", addr, len, flags, topdown); - if (len > mm->task_size) - return -ENOMEM; - if (len & ((1ul << pshift) - 1)) - return -EINVAL; - if (fixed && (addr & ((1ul << pshift) - 1))) - return -EINVAL; - if (fixed && addr > (mm->task_size - len)) - return -ENOMEM; - /* If hint, make sure it matches our alignment restrictions */ if (!fixed && addr) { - addr = _ALIGN_UP(addr, 1ul << pshift); + addr = _ALIGN_UP(addr, page_size); slice_dbg(" aligned addr=%lx\n", addr); /* Ignore hint if it's too large or overlaps a VMA */ - if (addr > mm->task_size - len || + if (addr > high_limit - len || !slice_area_is_free(mm, addr, len)) addr = 0; } Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Fix fork() with 512TB process address space" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/64s/hash: Fix fork() with 512TB process address space to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From effc1b25088502fbd30305c79773de2d1f7470a6 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:37 +1100 Subject: powerpc/64s/hash: Fix fork() with 512TB process address space From: Nicholas Piggin <npiggin(a)gmail.com> commit effc1b25088502fbd30305c79773de2d1f7470a6 upstream. Hash unconditionally resets the addr_limit to default (128TB) when the mm context is initialised. If a process has > 128TB mappings when it forks, the child will not get the 512TB addr_limit, so accesses to valid > 128TB mappings will fail in the child. Fix this by only resetting the addr_limit to default if it was 0. Non zero indicates it was duplicated from the parent (0 means exec()). Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/mmu_context_book3s64.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/powerpc/mm/mmu_context_book3s64.c +++ b/arch/powerpc/mm/mmu_context_book3s64.c @@ -93,11 +93,11 @@ static int hash__init_new_context(struct return index; /* - * We do switch_slb() early in fork, even before we setup the - * mm->context.addr_limit. Default to max task size so that we copy the - * default values to paca which will help us to handle slb miss early. + * In the case of exec, use the default limit, + * otherwise inherit it from the mm we are duplicating. */ - mm->context.addr_limit = DEFAULT_MAP_WINDOW_USER64; + if (!mm->context.addr_limit) + mm->context.addr_limit = DEFAULT_MAP_WINDOW_USER64; /* * The old code would re-promote on fork, we don't do that when using Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s: Fix masking of SRR1 bits on instruction fault" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/64s: Fix masking of SRR1 bits on instruction fault to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 475b581ff57bc01437cbc680e281869918447763 Mon Sep 17 00:00:00 2001 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Tue, 14 Nov 2017 15:48:47 +1100 Subject: powerpc/64s: Fix masking of SRR1 bits on instruction fault From: Michael Ellerman <mpe(a)ellerman.id.au> commit 475b581ff57bc01437cbc680e281869918447763 upstream. On 64-bit Book3s, when we take an instruction fault the reason for the fault may be reported in SRR1. For data faults the reason is reported in DSISR (Data Storage Instruction Status Register). The reasons reported in each do not necessarily correspond, so we mask the SRR1 bits before copying them to the DSISR, which is then used by the page fault code. Prior to commit b4c001dc44f0 ("powerpc/mm: Use symbolic constants for filtering SRR1 bits on ISIs") we used a hard-coded mask of 0x58200000, which corresponds to: DSISR_NOHPTE 0x40000000 /* no translation found */ DSISR_NOEXEC_OR_G 0x10000000 /* exec of no-exec or guarded */ DSISR_PROTFAULT 0x08000000 /* protection fault */ DSISR_KEYFAULT 0x00200000 /* Storage Key fault */ That commit added a #define for the mask, DSISR_SRR1_MATCH_64S, but incorrectly used a different similarly named DSISR_BAD_FAULT_64S. This had the effect of changing the mask to 0xa43a0000, which omits everything but DSISR_KEYFAULT. Luckily this had no visible effect, because in practice we hardly use the DSISR bits. The lack of DSISR_NOHPTE means a TLB flush optimisation was missed in the native HPTE code, and DSISR_NOEXEC_OR_G and DSISR_PROTFAULT are both only used to trigger rare warnings. So we got lucky, but let's fix it. The new value only has bits between 17 and 30 set, so we can continue to use andis. Fixes: b4c001dc44f0 ("powerpc/mm: Use symbolic constants for filtering SRR1 bits on ISIs") Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/exceptions-64s.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -542,7 +542,7 @@ EXC_COMMON_BEGIN(instruction_access_comm RECONCILE_IRQ_STATE(r10, r11) ld r12,_MSR(r1) ld r3,_NIP(r1) - andis. r4,r12,DSISR_BAD_FAULT_64S@h + andis. r4,r12,DSISR_SRR1_MATCH_64S@h li r5,0x400 std r3,_DAR(r1) std r4,_DSISR(r1) Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.14/powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch queue-4.14/powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 35602f82d0c765f991420e319c8d3a596c921eb8 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:38 +1100 Subject: powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary From: Nicholas Piggin <npiggin(a)gmail.com> commit 35602f82d0c765f991420e319c8d3a596c921eb8 upstream. While mapping hints with a length that cross 128TB are disallowed, MAP_FIXED allocations that cross 128TB are allowed. These are failing on hash (on radix they succeed). Add an additional case for fixed mappings to expand the addr_limit when crossing 128TB. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/slice.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -418,7 +418,7 @@ unsigned long slice_get_unmapped_area(un unsigned long high_limit; high_limit = DEFAULT_MAP_WINDOW; - if (addr >= high_limit) + if (addr >= high_limit || (fixed && (addr + len > high_limit))) high_limit = TASK_SIZE; if (len > high_limit) Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2017