From patchwork Fri Jul 23 22:50:01 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 485134 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F4044C4320A for ; Fri, 23 Jul 2021 22:50:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DA01560F38 for ; Fri, 23 Jul 2021 22:50:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232902AbhGWWJb (ORCPT ); Fri, 23 Jul 2021 18:09:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:49026 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231954AbhGWWJa (ORCPT ); Fri, 23 Jul 2021 18:09:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 311D760F36; Fri, 23 Jul 2021 22:50:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1627080602; bh=6r5/HJ8Xu+CJBD2/fZuj9CmQNGPet2FahetOQYy6cCU=; h=Date:From:To:Subject:In-Reply-To:From; b=zisOZAZYy5U7NKHdLj6qFaRm9kf91WuFs2H1iPdH0KOvr1rspr2POu1WodD+oIMN2 wc6GaU1reGQnkhYNKm+lLIP0g4Ig2qMTh2k/WshKqD2dmiXvN9a9IJa9xImQBxb4Rb vLvA1ATuiDsFVQk3mQrgHS4YISUZdmYJt45fyGPk= Date: Fri, 23 Jul 2021 15:50:01 -0700 From: Andrew Morton To: aarcange@redhat.com, adelva@google.com, akpm@linux-foundation.org, andreyknvl@gmail.com, catalin.marinas@arm.com, Dave.Martin@arm.com, eugenis@google.com, linux-mm@kvack.org, lokeshgidra@google.com, mitchp@google.com, mm-commits@vger.kernel.org, pcc@google.com, stable@vger.kernel.org, torvalds@linux-foundation.org, vincenzo.frascino@arm.com, will@kernel.org, willmcvicker@google.com Subject: [patch 01/15] userfaultfd: do not untag user pointers Message-ID: <20210723225001.ohM2zubyp%akpm@linux-foundation.org> In-Reply-To: <20210723154926.c6cda0f262b1990b950a5886@linux-foundation.org> User-Agent: s-nail v14.8.16 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Peter Collingbourne Subject: userfaultfd: do not untag user pointers Patch series "userfaultfd: do not untag user pointers", v5. If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. Also change the kselftest to use mmap so that it doesn't encounter this problem. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c This patch (of 2): If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), as well as being consistent with the existing tagged address ABI documentation relating to how ioctl arguments are handled. The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag user pointers") plus some fixups to some additional calls to validate_range that have appeared since then. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c Link: https://lkml.kernel.org/r/20210714195437.118982-1-pcc@google.com Link: https://lkml.kernel.org/r/20210714195437.118982-2-pcc@google.com Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0a25501b Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Signed-off-by: Peter Collingbourne Reviewed-by: Andrey Konovalov Reviewed-by: Catalin Marinas Cc: Alistair Delva Cc: Andrea Arcangeli Cc: Dave Martin Cc: Evgenii Stepanov Cc: Lokesh Gidra Cc: Mitch Phillips Cc: Vincenzo Frascino Cc: Will Deacon Cc: William McVicker Cc: [5.4] Signed-off-by: Andrew Morton --- Documentation/arm64/tagged-address-abi.rst | 26 +++++++++++++------ fs/userfaultfd.c | 26 ++++++++----------- 2 files changed, 30 insertions(+), 22 deletions(-) --- a/Documentation/arm64/tagged-address-abi.rst~userfaultfd-do-not-untag-user-pointers +++ a/Documentation/arm64/tagged-address-abi.rst @@ -45,14 +45,24 @@ how the user addresses are used by the k 1. User addresses not accessed by the kernel but used for address space management (e.g. ``mprotect()``, ``madvise()``). The use of valid - tagged pointers in this context is allowed with the exception of - ``brk()``, ``mmap()`` and the ``new_address`` argument to - ``mremap()`` as these have the potential to alias with existing - user addresses. - - NOTE: This behaviour changed in v5.6 and so some earlier kernels may - incorrectly accept valid tagged pointers for the ``brk()``, - ``mmap()`` and ``mremap()`` system calls. + tagged pointers in this context is allowed with these exceptions: + + - ``brk()``, ``mmap()`` and the ``new_address`` argument to + ``mremap()`` as these have the potential to alias with existing + user addresses. + + NOTE: This behaviour changed in v5.6 and so some earlier kernels may + incorrectly accept valid tagged pointers for the ``brk()``, + ``mmap()`` and ``mremap()`` system calls. + + - The ``range.start``, ``start`` and ``dst`` arguments to the + ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from + ``userfaultfd()``, as fault addresses subsequently obtained by reading + the file descriptor will be untagged, which may otherwise confuse + tag-unaware programs. + + NOTE: This behaviour changed in v5.14 and so some earlier kernels may + incorrectly accept valid tagged pointers for this system call. 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI relaxation is disabled by default and the application thread needs to --- a/fs/userfaultfd.c~userfaultfd-do-not-untag-user-pointers +++ a/fs/userfaultfd.c @@ -1236,23 +1236,21 @@ static __always_inline void wake_userfau } static __always_inline int validate_range(struct mm_struct *mm, - __u64 *start, __u64 len) + __u64 start, __u64 len) { __u64 task_size = mm->task_size; - *start = untagged_addr(*start); - - if (*start & ~PAGE_MASK) + if (start & ~PAGE_MASK) return -EINVAL; if (len & ~PAGE_MASK) return -EINVAL; if (!len) return -EINVAL; - if (*start < mmap_min_addr) + if (start < mmap_min_addr) return -EINVAL; - if (*start >= task_size) + if (start >= task_size) return -EINVAL; - if (len > task_size - *start) + if (len > task_size - start) return -EINVAL; return 0; } @@ -1316,7 +1314,7 @@ static int userfaultfd_register(struct u vm_flags |= VM_UFFD_MINOR; } - ret = validate_range(mm, &uffdio_register.range.start, + ret = validate_range(mm, uffdio_register.range.start, uffdio_register.range.len); if (ret) goto out; @@ -1522,7 +1520,7 @@ static int userfaultfd_unregister(struct if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) goto out; - ret = validate_range(mm, &uffdio_unregister.start, + ret = validate_range(mm, uffdio_unregister.start, uffdio_unregister.len); if (ret) goto out; @@ -1671,7 +1669,7 @@ static int userfaultfd_wake(struct userf if (copy_from_user(&uffdio_wake, buf, sizeof(uffdio_wake))) goto out; - ret = validate_range(ctx->mm, &uffdio_wake.start, uffdio_wake.len); + ret = validate_range(ctx->mm, uffdio_wake.start, uffdio_wake.len); if (ret) goto out; @@ -1711,7 +1709,7 @@ static int userfaultfd_copy(struct userf sizeof(uffdio_copy)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_copy.dst, uffdio_copy.len); + ret = validate_range(ctx->mm, uffdio_copy.dst, uffdio_copy.len); if (ret) goto out; /* @@ -1768,7 +1766,7 @@ static int userfaultfd_zeropage(struct u sizeof(uffdio_zeropage)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_zeropage.range.start, + ret = validate_range(ctx->mm, uffdio_zeropage.range.start, uffdio_zeropage.range.len); if (ret) goto out; @@ -1818,7 +1816,7 @@ static int userfaultfd_writeprotect(stru sizeof(struct uffdio_writeprotect))) return -EFAULT; - ret = validate_range(ctx->mm, &uffdio_wp.range.start, + ret = validate_range(ctx->mm, uffdio_wp.range.start, uffdio_wp.range.len); if (ret) return ret; @@ -1866,7 +1864,7 @@ static int userfaultfd_continue(struct u sizeof(uffdio_continue) - (sizeof(__s64)))) goto out; - ret = validate_range(ctx->mm, &uffdio_continue.range.start, + ret = validate_range(ctx->mm, uffdio_continue.range.start, uffdio_continue.range.len); if (ret) goto out; From patchwork Fri Jul 23 22:50:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 485133 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0791C4320A for ; Fri, 23 Jul 2021 22:50:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 82D3A60F36 for ; Fri, 23 Jul 2021 22:50:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232909AbhGWWJj (ORCPT ); Fri, 23 Jul 2021 18:09:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:49198 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231954AbhGWWJj (ORCPT ); Fri, 23 Jul 2021 18:09:39 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7F39560EB5; Fri, 23 Jul 2021 22:50:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1627080611; bh=xpuL7eQJ7xIPE/XkgeA272A2+E7I7sd5biWYgp+buAw=; h=Date:From:To:Subject:In-Reply-To:From; b=AJJZqaI5Bfft/bWGO1YiP4dhQEbOZH/9BzClDlW/vYxzKmHONpSrgTH1RW/yMlufC n2GokPJWggESxvNkdmzeZbDYIFtocQoVYAY/DIOGnnFD7Hym4FK3D+ELushuwhNVUT yV3tq/6jrs9iYnCigvx0cGo/uJ20vsQ0VuleLJ24= Date: Fri, 23 Jul 2021 15:50:11 -0700 From: Andrew Morton To: akpm@linux-foundation.org, dvyukov@google.com, elver@google.com, glider@google.com, gregkh@linuxfoundation.org, linux-mm@kvack.org, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 04/15] kfence: move the size check to the beginning of __kfence_alloc() Message-ID: <20210723225011.pURAgvl2s%akpm@linux-foundation.org> In-Reply-To: <20210723154926.c6cda0f262b1990b950a5886@linux-foundation.org> User-Agent: s-nail v14.8.16 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Alexander Potapenko Subject: kfence: move the size check to the beginning of __kfence_alloc() Check the allocation size before toggling kfence_allocation_gate. This way allocations that can't be served by KFENCE will not result in waiting for another CONFIG_KFENCE_SAMPLE_INTERVAL without allocating anything. Link: https://lkml.kernel.org/r/20210714092222.1890268-1-glider@google.com Signed-off-by: Alexander Potapenko Suggested-by: Marco Elver Reviewed-by: Marco Elver Cc: Dmitry Vyukov Cc: Marco Elver Cc: Greg Kroah-Hartman Cc: [5.12+] Signed-off-by: Andrew Morton --- mm/kfence/core.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/mm/kfence/core.c~kfence-move-the-size-check-to-the-beginning-of-__kfence_alloc +++ a/mm/kfence/core.c @@ -734,6 +734,13 @@ void kfence_shutdown_cache(struct kmem_c void *__kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags) { /* + * Perform size check before switching kfence_allocation_gate, so that + * we don't disable KFENCE without making an allocation. + */ + if (size > PAGE_SIZE) + return NULL; + + /* * allocation_gate only needs to become non-zero, so it doesn't make * sense to continue writing to it and pay the associated contention * cost, in case we have a large number of concurrent allocations. @@ -757,9 +764,6 @@ void *__kfence_alloc(struct kmem_cache * if (!READ_ONCE(kfence_enabled)) return NULL; - if (size > PAGE_SIZE) - return NULL; - return kfence_guarded_alloc(s, size, flags); } From patchwork Fri Jul 23 22:50:17 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 485132 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7ECBCC432BE for ; Fri, 23 Jul 2021 22:50:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 644CA60F36 for ; Fri, 23 Jul 2021 22:50:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231954AbhGWWJq (ORCPT ); Fri, 23 Jul 2021 18:09:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:49332 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233043AbhGWWJp (ORCPT ); Fri, 23 Jul 2021 18:09:45 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9975B60EB5; Fri, 23 Jul 2021 22:50:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1627080617; bh=Ie8KW1gqKVigYgdWdvXa5xrDDnPZVyW4txtPpNygGLQ=; h=Date:From:To:Subject:In-Reply-To:From; b=nhTvl0ebtSzDg/eYZOyngyAZCdsPonVl+DoSUxm8gqp3tQWRjmVI1r/3rfzHY1lGZ docantuwxdFgUvdmJUa3MmEGNJ8KdVDBbq+i0Tt9fHdtzQGwwEzI+C3vV61c5bUOUu F0mVURPP2k1zQXZLxvnDXCLmhkT9zSucOA2L/rNA= Date: Fri, 23 Jul 2021 15:50:17 -0700 From: Andrew Morton To: akpm@linux-foundation.org, chaitanya.kulkarni@wdc.com, hch@lst.de, ira.weiny@intel.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 06/15] mm: call flush_dcache_page() in memcpy_to_page() and memzero_page() Message-ID: <20210723225017.xFO0jZesP%akpm@linux-foundation.org> In-Reply-To: <20210723154926.c6cda0f262b1990b950a5886@linux-foundation.org> User-Agent: s-nail v14.8.16 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Christoph Hellwig Subject: mm: call flush_dcache_page() in memcpy_to_page() and memzero_page() memcpy_to_page and memzero_page can write to arbitrary pages, which could be in the page cache or in high memory, so call flush_kernel_dcache_pages to flush the dcache. This is a problem when using these helpers on dcache challeneged architectures. Right now there are just a few users, chances are no one used the PC floppy dr\u0456ver, the aha1542 driver for an ISA SCSI HBA, and a few advanced and optional btrfs and ext4 features on those platforms yet since the conversion. Link: https://lkml.kernel.org/r/20210713055231.137602-2-hch@lst.de Fixes: bb90d4bc7b6a ("mm/highmem: Lift memcpy_[to|from]_page to core") Fixes: 28961998f858 ("iov_iter: lift memzero_page() to highmem.h") Signed-off-by: Christoph Hellwig Reviewed-by: Ira Weiny Cc: Chaitanya Kulkarni Cc: Signed-off-by: Andrew Morton --- include/linux/highmem.h | 2 ++ 1 file changed, 2 insertions(+) --- a/include/linux/highmem.h~mm-call-flush_dcache_page-in-memcpy_to_page-and-memzero_page +++ a/include/linux/highmem.h @@ -318,6 +318,7 @@ static inline void memcpy_to_page(struct VM_BUG_ON(offset + len > PAGE_SIZE); memcpy(to + offset, from, len); + flush_dcache_page(page); kunmap_local(to); } @@ -325,6 +326,7 @@ static inline void memzero_page(struct p { char *addr = kmap_atomic(page); memset(addr + offset, 0, len); + flush_dcache_page(page); kunmap_atomic(addr); } From patchwork Fri Jul 23 22:50:26 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 485131 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 484F6C4320A for ; Fri, 23 Jul 2021 22:50:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 28B9260F42 for ; Fri, 23 Jul 2021 22:50:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233081AbhGWWJ5 (ORCPT ); Fri, 23 Jul 2021 18:09:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:49526 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233043AbhGWWJz (ORCPT ); Fri, 23 Jul 2021 18:09:55 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id DBAB760EB5; Fri, 23 Jul 2021 22:50:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1627080627; bh=Af+pfxWxJMb/31NbbUMPrHBKJJrq7R7LN/ftQlVsklE=; h=Date:From:To:Subject:In-Reply-To:From; b=QGVk7b/jxiZuELONj2x60af3k2eiP2HylgBbSmQKy6n5Gm0PC/iyQurLMn5fxJylH UhXkzcUuK+1GAr8ZS0rC3ciEtnSHJLkK12Gv44Q2t6H7Pkl/lOVsGT2kr5Jlc82JAK 3FH+DdqbX6oASAacIVOGC1upmTZdXRTTf7xyssH8= Date: Fri, 23 Jul 2021 15:50:26 -0700 From: Andrew Morton To: akpm@linux-foundation.org, david@redhat.com, groug@kaod.org, linux-mm@kvack.org, mm-commits@vger.kernel.org, rppt@linux.ibm.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 09/15] memblock: make for_each_mem_range() traverse MEMBLOCK_HOTPLUG regions Message-ID: <20210723225026.A8uSa0Z-U%akpm@linux-foundation.org> In-Reply-To: <20210723154926.c6cda0f262b1990b950a5886@linux-foundation.org> User-Agent: s-nail v14.8.16 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Rapoport Subject: memblock: make for_each_mem_range() traverse MEMBLOCK_HOTPLUG regions Commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()") didn't take into account that when there is movable_node parameter in the kernel command line, for_each_mem_range() would skip ranges marked with MEMBLOCK_HOTPLUG. The page table setup code in POWER uses for_each_mem_range() to create the linear mapping of the physical memory and since the regions marked as MEMORY_HOTPLUG are skipped, they never make it to the linear map. A later access to the memory in those ranges will fail: [ 2.271743] BUG: Unable to handle kernel data access on write at 0xc000000400000000 [ 2.271984] Faulting instruction address: 0xc00000000008a3c0 [ 2.272568] Oops: Kernel access of bad area, sig: 11 [#1] [ 2.272683] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries [ 2.273063] Modules linked in: [ 2.273435] CPU: 0 PID: 53 Comm: kworker/u2:0 Not tainted 5.13.0 #7 [ 2.273832] NIP: c00000000008a3c0 LR: c0000000003c1ed8 CTR: 0000000000000040 [ 2.273918] REGS: c000000008a57770 TRAP: 0300 Not tainted (5.13.0) [ 2.274036] MSR: 8000000002009033 CR: 84222202 XER: 20040000 [ 2.274454] CFAR: c0000000003c1ed4 DAR: c000000400000000 DSISR: 42000000 IRQMASK: 0 [ 2.274454] GPR00: c0000000003c1ed8 c000000008a57a10 c0000000019da700 c000000400000000 [ 2.274454] GPR04: 0000000000000280 0000000000000180 0000000000000400 0000000000000200 [ 2.274454] GPR08: 0000000000000100 0000000000000080 0000000000000040 0000000000000300 [ 2.274454] GPR12: 0000000000000380 c000000001bc0000 c0000000001660c8 c000000006337e00 [ 2.274454] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.274454] GPR20: 0000000040000000 0000000020000000 c000000001a81990 c000000008c30000 [ 2.274454] GPR24: c000000008c20000 c000000001a81998 000fffffffff0000 c000000001a819a0 [ 2.274454] GPR28: c000000001a81908 c00c000001000000 c000000008c40000 c000000008a64680 [ 2.275520] NIP [c00000000008a3c0] clear_user_page+0x50/0x80 [ 2.276333] LR [c0000000003c1ed8] __handle_mm_fault+0xc88/0x1910 [ 2.276688] Call Trace: [ 2.276839] [c000000008a57a10] [c0000000003c1e94] __handle_mm_fault+0xc44/0x1910 (unreliable) [ 2.277142] [c000000008a57af0] [c0000000003c2c90] handle_mm_fault+0x130/0x2a0 [ 2.277331] [c000000008a57b40] [c0000000003b5f08] __get_user_pages+0x248/0x610 [ 2.277541] [c000000008a57c40] [c0000000003b848c] __get_user_pages_remote+0x12c/0x3e0 [ 2.277768] [c000000008a57cd0] [c000000000473f24] get_arg_page+0x54/0xf0 [ 2.277959] [c000000008a57d10] [c000000000474a7c] copy_string_kernel+0x11c/0x210 [ 2.278159] [c000000008a57d80] [c00000000047663c] kernel_execve+0x16c/0x220 [ 2.278361] [c000000008a57dd0] [c000000000166270] call_usermodehelper_exec_async+0x1b0/0x2f0 [ 2.278543] [c000000008a57e10] [c00000000000d5ec] ret_from_kernel_thread+0x5c/0x70 [ 2.278870] Instruction dump: [ 2.279214] 79280fa4 79271764 79261f24 794ae8e2 7ca94214 7d683a14 7c893a14 7d893050 [ 2.279416] 7d4903a6 60000000 60000000 60000000 <7c001fec> 7c091fec 7c081fec 7c051fec [ 2.280193] ---[ end trace 490b8c67e6075e09 ]--- Making for_each_mem_range() include MEMBLOCK_HOTPLUG regions in the traversal fixes this issue. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976100 Link: https://lkml.kernel.org/r/20210712071132.20902-1-rppt@kernel.org Fixes: b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Signed-off-by: Mike Rapoport Tested-by: Greg Kurz Reviewed-by: David Hildenbrand Cc: [5.10+] Signed-off-by: Andrew Morton --- include/linux/memblock.h | 4 ++-- mm/memblock.c | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) --- a/include/linux/memblock.h~memblock-make-for_each_mem_range-traverse-memblock_hotplug-regions +++ a/include/linux/memblock.h @@ -209,7 +209,7 @@ static inline void __next_physmem_range( */ #define for_each_mem_range(i, p_start, p_end) \ __for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE, \ - MEMBLOCK_NONE, p_start, p_end, NULL) + MEMBLOCK_HOTPLUG, p_start, p_end, NULL) /** * for_each_mem_range_rev - reverse iterate through memblock areas from @@ -220,7 +220,7 @@ static inline void __next_physmem_range( */ #define for_each_mem_range_rev(i, p_start, p_end) \ __for_each_mem_range_rev(i, &memblock.memory, NULL, NUMA_NO_NODE, \ - MEMBLOCK_NONE, p_start, p_end, NULL) + MEMBLOCK_HOTPLUG, p_start, p_end, NULL) /** * for_each_reserved_mem_range - iterate over all reserved memblock areas --- a/mm/memblock.c~memblock-make-for_each_mem_range-traverse-memblock_hotplug-regions +++ a/mm/memblock.c @@ -947,7 +947,8 @@ static bool should_skip_region(struct me return true; /* skip hotpluggable memory regions if needed */ - if (movable_node_is_enabled() && memblock_is_hotpluggable(m)) + if (movable_node_is_enabled() && memblock_is_hotpluggable(m) && + !(flags & MEMBLOCK_HOTPLUG)) return true; /* if we want mirror memory skip non-mirror memory regions */ From patchwork Fri Jul 23 22:50:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 485130 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2029BC4320A for ; Fri, 23 Jul 2021 22:50:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 067CF60F36 for ; Fri, 23 Jul 2021 22:50:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233126AbhGWWKS (ORCPT ); Fri, 23 Jul 2021 18:10:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:49870 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233064AbhGWWKQ (ORCPT ); Fri, 23 Jul 2021 18:10:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5677460EB5; Fri, 23 Jul 2021 22:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1627080645; bh=5JUSCAQlPFtlAg3XzVomObTQ+RoMD50OOdwH73RgAvI=; h=Date:From:To:Subject:In-Reply-To:From; b=ZtMY1iwyBR8rrR486460lmnTzE7qwHaJbQ/XhIICqNQ1VIc9dyiUOH+UZ40jFODIa RZT6JP3GwcnJscD8pBQEWXbMjYmlmOe2IthyPtQZzO8wYzFat27jL4WW0sHtooZ947 H2eJTfumbtqhS1B9dY/XpBy/MQerfZvRbfCWcpUQ= Date: Fri, 23 Jul 2021 15:50:44 -0700 From: Andrew Morton To: akpm@linux-foundation.org, bugs+kernel.org@dtnr.ch, dhowells@redhat.com, linux-mm@kvack.org, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, willy@infradead.org Subject: [patch 15/15] hugetlbfs: fix mount mode command line processing Message-ID: <20210723225044.DpiHGbzxj%akpm@linux-foundation.org> In-Reply-To: <20210723154926.c6cda0f262b1990b950a5886@linux-foundation.org> User-Agent: s-nail v14.8.16 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Kravetz Subject: hugetlbfs: fix mount mode command line processing In commit 32021982a324 ("hugetlbfs: Convert to fs_context") processing of the mount mode string was changed from match_octal() to fsparam_u32. This changed existing behavior as match_octal does not require octal values to have a '0' prefix, but fsparam_u32 does. Use fsparam_u32oct which provides the same behavior as match_octal. Link: https://lkml.kernel.org/r/20210721183326.102716-1-mike.kravetz@oracle.com Fixes: 32021982a324 ("hugetlbfs: Convert to fs_context") Signed-off-by: Mike Kravetz Reported-by: Dennis Camera Reviewed-by: Matthew Wilcox (Oracle) Cc: David Howells Cc: Al Viro Cc: Signed-off-by: Andrew Morton --- fs/hugetlbfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/hugetlbfs/inode.c~hugetlbfs-fix-mount-mode-command-line-processing +++ a/fs/hugetlbfs/inode.c @@ -77,7 +77,7 @@ enum hugetlb_param { static const struct fs_parameter_spec hugetlb_fs_parameters[] = { fsparam_u32 ("gid", Opt_gid), fsparam_string("min_size", Opt_min_size), - fsparam_u32 ("mode", Opt_mode), + fsparam_u32oct("mode", Opt_mode), fsparam_string("nr_inodes", Opt_nr_inodes), fsparam_string("pagesize", Opt_pagesize), fsparam_string("size", Opt_size),