From patchwork Fri Apr 15 02:13:31 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 562190 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8091CC4332F for ; Fri, 15 Apr 2022 02:13:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348596AbiDOCQD (ORCPT ); Thu, 14 Apr 2022 22:16:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346914AbiDOCQB (ORCPT ); Thu, 14 Apr 2022 22:16:01 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 498F41D334; Thu, 14 Apr 2022 19:13:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F31CDB82BF3; Fri, 15 Apr 2022 02:13:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2123C385AA; Fri, 15 Apr 2022 02:13:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988811; bh=kJy8HCH2PF88Ukvq4CiNIs0nm73iZq6YeCxUJq69zzo=; h=Date:To:From:In-Reply-To:Subject:From; b=uu+rQXmnuzQrdBDHHnFepv7hC5HElUNTlNXY42oY1vQJEMWbF/Q9wg4Vownuq6Ui5 WNXGhnOtNdo/iIFhR0T701CvB8ZyO0EC3OsG1hnJydoulir/sSqJ1sHRsrEQPAB5sj ixYL82RjBGRRKqdqH5jet6cUOiNBumH6CyLquD+A= Date: Thu, 14 Apr 2022 19:13:31 -0700 To: willy@infradead.org, stable@vger.kernel.org, rppt@kernel.org, lkp@intel.com, axelrasmussen@google.com, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 03/14] mm/secretmem: fix panic when growing a memfd_secret Message-Id: <20220415021331.A2123C385AA@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Axel Rasmussen Subject: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); The basic reason for this is, when we grow with ftruncate, we call down into simple_setattr, and then truncate_inode_pages_range, and eventually we try to zero part of the memory. The normal truncation code does this via the direct map (i.e., it calls page_address() and hands that to memset()). For memfd_secret though, we specifically don't map our pages via the direct map (i.e. we call set_direct_map_invalid_noflush() on every fault). So the address returned by page_address() isn't useful, and when we try to memset() with it we panic. This patch avoids the panic by implementing a custom setattr for memfd_secret, which detects resizes specifically (setting the size for the first time works just fine, since there are no existing pages to try to zero), and rejects them with EINVAL. One could argue growing should be supported, but I think that will require a significantly more lengthy change. So, I propose a minimal fix for the benefit of stable kernels, and then perhaps to extend memfd_secret to support growing in a separate patch. [1]: [ 774.320433] BUG: unable to handle page fault for address: ffffa0a889277028 [ 774.322297] #PF: supervisor write access in kernel mode [ 774.323306] #PF: error_code(0x0002) - not-present page [ 774.324296] PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 [ 774.325841] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [ 774.326934] CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 [ 774.328074] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 774.329732] RIP: 0010:memset_erms+0x9/0x10 [ 774.330474] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 [ 774.333543] RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 [ 774.334404] RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 [ 774.335545] RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 [ 774.336685] RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 [ 774.337929] R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 [ 774.339236] R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 [ 774.340356] FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 [ 774.341635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 774.342535] CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 [ 774.343651] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 774.344780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 774.345938] Call Trace: [ 774.346334] [ 774.346671] ? zero_user_segments+0x82/0x190 [ 774.347346] truncate_inode_partial_folio+0xd4/0x2a0 [ 774.348128] truncate_inode_pages_range+0x380/0x830 [ 774.348904] truncate_setsize+0x63/0x80 [ 774.349530] simple_setattr+0x37/0x60 [ 774.350102] notify_change+0x3d8/0x4d0 [ 774.350681] do_sys_ftruncate+0x162/0x1d0 [ 774.351302] __x64_sys_ftruncate+0x1c/0x20 [ 774.351936] do_syscall_64+0x44/0xa0 [ 774.352486] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 774.353284] RIP: 0033:0x7f72947c392b [ 774.354001] Code: 77 05 c3 0f 1f 40 00 48 8b 15 41 85 0c 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 4d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 11 85 0c 00 f7 d8 [ 774.357938] RSP: 002b:00007ffcad62a1a8 EFLAGS: 00000202 ORIG_RAX: 000000000000004d [ 774.359116] RAX: ffffffffffffffda RBX: 000055f47662b440 RCX: 00007f72947c392b [ 774.360186] RDX: 0000000000000028 RSI: 0000000000000028 RDI: 0000000000000003 [ 774.361246] RBP: 00007ffcad62a1c0 R08: 0000000000000003 R09: 0000000000000000 [ 774.362324] R10: 00007f72946dc230 R11: 0000000000000202 R12: 000055f47662b0e0 [ 774.363393] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 774.364470] [ 774.364807] Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet [ 774.367325] CR2: ffffa0a889277028 [ 774.367838] ---[ end trace 0000000000000000 ]--- [ 774.368543] RIP: 0010:memset_erms+0x9/0x10 [ 774.369187] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 [ 774.372282] RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 [ 774.373372] RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 [ 774.374814] RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 [ 774.376248] RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 [ 774.377687] R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 [ 774.379135] R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 [ 774.380550] FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 [ 774.382177] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 774.383329] CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 [ 774.384763] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 774.386229] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 774.387664] Kernel panic - not syncing: Fatal exception [ 774.388863] Kernel Offset: 0x8000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 774.391014] ---[ end Kernel panic - not syncing: Fatal exception ]--- [lkp@intel.com: secretmem_iops can be static] Signed-off-by: kernel test robot [axelrasmussen@google.com: return EINVAL] Link: https://lkml.kernel.org/r/20220412193023.279320-1-axelrasmussen@google.com Link: https://lkml.kernel.org/r/20220324210909.1843814-1-axelrasmussen@google.com Signed-off-by: Axel Rasmussen Signed-off-by: Axel Rasmussen Cc: Mike Rapoport Cc: Matthew Wilcox Cc: Cc: kernel test robot Signed-off-by: Andrew Morton --- mm/secretmem.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/mm/secretmem.c~mm-secretmem-fix-panic-when-growing-a-memfd_secret +++ a/mm/secretmem.c @@ -158,6 +158,22 @@ const struct address_space_operations se .isolate_page = secretmem_isolate_page, }; +static int secretmem_setattr(struct user_namespace *mnt_userns, + struct dentry *dentry, struct iattr *iattr) +{ + struct inode *inode = d_inode(dentry); + unsigned int ia_valid = iattr->ia_valid; + + if ((ia_valid & ATTR_SIZE) && inode->i_size) + return -EINVAL; + + return simple_setattr(mnt_userns, dentry, iattr); +} + +static const struct inode_operations secretmem_iops = { + .setattr = secretmem_setattr, +}; + static struct vfsmount *secretmem_mnt; static struct file *secretmem_file_create(unsigned long flags) @@ -177,6 +193,7 @@ static struct file *secretmem_file_creat mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER); mapping_set_unevictable(inode->i_mapping); + inode->i_op = &secretmem_iops; inode->i_mapping->a_ops = &secretmem_aops; /* pretend we are a normal file with zero size */ From patchwork Fri Apr 15 02:13:43 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 563103 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AA82C4332F for ; Fri, 15 Apr 2022 02:13:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348600AbiDOCQQ (ORCPT ); Thu, 14 Apr 2022 22:16:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348598AbiDOCQM (ORCPT ); Thu, 14 Apr 2022 22:16:12 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05F161A393; Thu, 14 Apr 2022 19:13:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9559262212; Fri, 15 Apr 2022 02:13:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E89F1C385A5; Fri, 15 Apr 2022 02:13:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988824; bh=/uR13Qq9wqBGR9IH2YJtOSDEkWsRKu9t9fGiJRj36Sw=; h=Date:To:From:In-Reply-To:Subject:From; b=ru4zzQgZZv5wnCe2MqmiPW8Mrkv5lbrCHfuRGSRPfGzWp6b0IJVfzfc9fiTrqDkhM WcRWTA0x8/4DpkeTVfJ4wJynVxaMlZv2dTj/CObVECCyS2GEbjBlc4Iz2AB+3OL09Y 4nZzArhd+1H5VkjZvXg5BXICp8JqjE77qlhwYb8s= Date: Thu, 14 Apr 2022 19:13:43 -0700 To: stable@vger.kernel.org, richard.weiyang@gmail.com, mhocko@suse.com, marmarek@invisiblethingslab.com, david@redhat.com, jgross@suse.com, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 07/14] mm, page_alloc: fix build_zonerefs_node() Message-Id: <20220415021343.E89F1C385A5@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Juergen Gross Subject: mm, page_alloc: fix build_zonerefs_node() Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") only zones with free memory are included in a built zonelist. This is problematic when e.g. all memory of a zone has been ballooned out when zonelists are being rebuilt. The decision whether to rebuild the zonelists when onlining new memory is done based on populated_zone() returning 0 for the zone the memory will be added to. The new zone is added to the zonelists only, if it has free memory pages (managed_zone() returns a non-zero value) after the memory has been onlined. This implies, that onlining memory will always free the added pages to the allocator immediately, but this is not true in all cases: when e.g. running as a Xen guest the onlined new memory will be added only to the ballooned memory list, it will be freed only when the guest is being ballooned up afterwards. Another problem with using managed_zone() for the decision whether a zone is being added to the zonelists is, that a zone with all memory used will in fact be removed from all zonelists in case the zonelists happen to be rebuilt. Use populated_zone() when building a zonelist as it has been done before that commit. There was a report that QubesOS (based on Xen) is hitting this problem. Xen has switched to use the zone device functionality in kernel 5.9 and QubesOS wants to use memory hotplugging for guests in order to be able to start a guest with minimal memory and expand it as needed. This was the report leading to the patch. Link: https://lkml.kernel.org/r/20220407120637.9035-1-jgross@suse.com Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") Signed-off-by: Juergen Gross Reported-by: Marek Marczykowski-Górecki Acked-by: Michal Hocko Acked-by: David Hildenbrand Cc: Marek Marczykowski-Górecki Reviewed-by: Wei Yang Cc: Signed-off-by: Andrew Morton --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/page_alloc.c~mm-page_alloc-fix-build_zonerefs_node +++ a/mm/page_alloc.c @@ -6131,7 +6131,7 @@ static int build_zonerefs_node(pg_data_t do { zone_type--; zone = pgdat->node_zones + zone_type; - if (managed_zone(zone)) { + if (populated_zone(zone)) { zoneref_set_zone(zone, &zonerefs[nr_zones++]); check_highest_zone(zone_type); } From patchwork Fri Apr 15 02:13:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 562189 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2873C433EF for ; Fri, 15 Apr 2022 02:13:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348598AbiDOCQT (ORCPT ); Thu, 14 Apr 2022 22:16:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348603AbiDOCQR (ORCPT ); Thu, 14 Apr 2022 22:16:17 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C49CA3190A; Thu, 14 Apr 2022 19:13:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 81815B82BF3; Fri, 15 Apr 2022 02:13:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 165E6C385A1; Fri, 15 Apr 2022 02:13:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988827; bh=xCFUpoOfjpWMzrJK4rQeRfdrhaHekCZ3L54NTJ5EtI4=; h=Date:To:From:In-Reply-To:Subject:From; b=ycWOACPY5a7e3zVT5ItlaYNvus4defw/J/e/c8W4DOpqF7kyfTZpfGPjnSKSWJSLg WVi4sf4P85uDAycs3JeZOR+SuEvkazKld/YR5Znn0NBnHZiRHcHgDWDpDVdtdMUNT2 q/RQQqJHqDJU73S+YE5iEatXN/rE2OxDkABGEeeU= Date: Thu, 14 Apr 2022 19:13:46 -0700 To: stable@vger.kernel.org, senozhatsky@chromium.org, ngupta@vflare.org, ivan@cloudflare.com, david@redhat.com, axboe@kernel.dk, minchan@kernel.org, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 08/14] mm: fix unexpected zeroed page mapping with zram swap Message-Id: <20220415021347.165E6C385A1@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Minchan Kim Subject: mm: fix unexpected zeroed page mapping with zram swap Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly. Link: https://lkml.kernel.org/r/YjTVVxIAsnKAXjTd@google.com Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device") Reported-by: Ivan Babrou Tested-by: Ivan Babrou Signed-off-by: Minchan Kim Cc: Nitin Gupta Cc: Sergey Senozhatsky Cc: Jens Axboe Cc: David Hildenbrand Cc: [4.14+] Signed-off-by: Andrew Morton --- mm/page_io.c | 54 ------------------------------------------------- 1 file changed, 54 deletions(-) --- a/mm/page_io.c~mm-fix-unexpected-zeroed-page-mapping-with-zram-swap +++ a/mm/page_io.c @@ -51,54 +51,6 @@ void end_swap_bio_write(struct bio *bio) bio_put(bio); } -static void swap_slot_free_notify(struct page *page) -{ - struct swap_info_struct *sis; - struct gendisk *disk; - swp_entry_t entry; - - /* - * There is no guarantee that the page is in swap cache - the software - * suspend code (at least) uses end_swap_bio_read() against a non- - * swapcache page. So we must check PG_swapcache before proceeding with - * this optimization. - */ - if (unlikely(!PageSwapCache(page))) - return; - - sis = page_swap_info(page); - if (data_race(!(sis->flags & SWP_BLKDEV))) - return; - - /* - * The swap subsystem performs lazy swap slot freeing, - * expecting that the page will be swapped out again. - * So we can avoid an unnecessary write if the page - * isn't redirtied. - * This is good for real swap storage because we can - * reduce unnecessary I/O and enhance wear-leveling - * if an SSD is used as the as swap device. - * But if in-memory swap device (eg zram) is used, - * this causes a duplicated copy between uncompressed - * data in VM-owned memory and compressed data in - * zram-owned memory. So let's free zram-owned memory - * and make the VM-owned decompressed page *dirty*, - * so the page should be swapped out somewhere again if - * we again wish to reclaim it. - */ - disk = sis->bdev->bd_disk; - entry.val = page_private(page); - if (disk->fops->swap_slot_free_notify && __swap_count(entry) == 1) { - unsigned long offset; - - offset = swp_offset(entry); - - SetPageDirty(page); - disk->fops->swap_slot_free_notify(sis->bdev, - offset); - } -} - static void end_swap_bio_read(struct bio *bio) { struct page *page = bio_first_page_all(bio); @@ -114,7 +66,6 @@ static void end_swap_bio_read(struct bio } SetPageUptodate(page); - swap_slot_free_notify(page); out: unlock_page(page); WRITE_ONCE(bio->bi_private, NULL); @@ -394,11 +345,6 @@ int swap_readpage(struct page *page, boo if (sis->flags & SWP_SYNCHRONOUS_IO) { ret = bdev_read_page(sis->bdev, swap_page_sector(page), page); if (!ret) { - if (trylock_page(page)) { - swap_slot_free_notify(page); - unlock_page(page); - } - count_vm_event(PSWPIN); goto out; } From patchwork Fri Apr 15 02:13:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 563102 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCE89C43217 for ; Fri, 15 Apr 2022 02:13:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348604AbiDOCQW (ORCPT ); Thu, 14 Apr 2022 22:16:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344722AbiDOCQV (ORCPT ); Thu, 14 Apr 2022 22:16:21 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73C981FCE9; Thu, 14 Apr 2022 19:13:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 36716B82B9C; Fri, 15 Apr 2022 02:13:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAC8DC385A5; Fri, 15 Apr 2022 02:13:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988833; bh=tfzIATRIEssyLcoxMcSK4FK9aTSQ+1j3NcOkbDQ7poc=; h=Date:To:From:In-Reply-To:Subject:From; b=v/8PQkr+vBRUpzYoyAmDsMC+FNaZgdN/7JjM3DKfCiYwBLv6+jLoHNhyFO/WXr4nE qwYN7QphbtQ2twQUh41vVFFcq26ZFTNE2J2Pa1ZMeHscAi6Dmzf8UrkdvtS8E4gXaU 8W4r2EC1yrQq12n3IP9HxmOuyhmN3FFe2PbB89YE= Date: Thu, 14 Apr 2022 19:13:52 -0700 To: stable@vger.kernel.org, naoya.horiguchi@nec.com, mike.kravetz@oracle.com, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 10/14] hugetlb: do not demote poisoned hugetlb pages Message-Id: <20220415021352.EAC8DC385A5@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Kravetz Subject: hugetlb: do not demote poisoned hugetlb pages It is possible for poisoned hugetlb pages to reside on the free lists. The huge page allocation routines which dequeue entries from the free lists make a point of avoiding poisoned pages. There is no such check and avoidance in the demote code path. If a hugetlb page on the is on a free list, poison will only be set in the head page rather then the page with the actual error. If such a page is demoted, then the poison flag may follow the wrong page. A page without error could have poison set, and a page with poison could not have the flag set. Check for poison before attempting to demote a hugetlb page. Also, return -EBUSY to the caller if only poisoned pages are on the free list. Link: https://lkml.kernel.org/r/20220307215707.50916-1-mike.kravetz@oracle.com Fixes: 8531fc6f52f5 ("hugetlb: add hugetlb demote page support") Signed-off-by: Mike Kravetz Reviewed-by: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton --- mm/hugetlb.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) --- a/mm/hugetlb.c~hugetlb-do-not-demote-poisoned-hugetlb-pages +++ a/mm/hugetlb.c @@ -3475,7 +3475,6 @@ static int demote_pool_huge_page(struct { int nr_nodes, node; struct page *page; - int rc = 0; lockdep_assert_held(&hugetlb_lock); @@ -3486,15 +3485,19 @@ static int demote_pool_huge_page(struct } for_each_node_mask_to_free(h, nr_nodes, node, nodes_allowed) { - if (!list_empty(&h->hugepage_freelists[node])) { - page = list_entry(h->hugepage_freelists[node].next, - struct page, lru); - rc = demote_free_huge_page(h, page); - break; + list_for_each_entry(page, &h->hugepage_freelists[node], lru) { + if (PageHWPoison(page)) + continue; + + return demote_free_huge_page(h, page); } } - return rc; + /* + * Only way to get here is if all pages on free lists are poisoned. + * Return -EBUSY so that caller will not retry. + */ + return -EBUSY; } #define HSTATE_ATTR_RO(_name) \ From patchwork Fri Apr 15 02:13:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 562188 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C34B9C433FE for ; Fri, 15 Apr 2022 02:14:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348619AbiDOCQh (ORCPT ); Thu, 14 Apr 2022 22:16:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348607AbiDOCQX (ORCPT ); Thu, 14 Apr 2022 22:16:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AF55ADD67; Thu, 14 Apr 2022 19:13:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BDBF36221F; Fri, 15 Apr 2022 02:13:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B0B3C385A1; Fri, 15 Apr 2022 02:13:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988836; bh=BKRZEFrsT7HckjP5sHfg9m9OXct1eM7WyctjCsktjL0=; h=Date:To:From:In-Reply-To:Subject:From; b=VobwKsOtL9/lzK56pUwdrV37Wx3MHwRc7XltBcqZa49C2J0b69TuppanPp8VWNJSh XehNRwrTmpTtowSP/bBxehpNm6xcHvk54SRhkZRkXycGcETO+3af9J6HSxF0dNYTPT D6jBG6ufJpIuv6tcbCDBrWkhg8cMyEpyw9wo40vQ= Date: Thu, 14 Apr 2022 19:13:55 -0700 To: viro@zeniv.linux.org.uk, surenb@google.com, stable@vger.kernel.org, sspatil@google.com, songliubraving@fb.com, shuah@kernel.org, rppt@kernel.org, rientjes@google.com, regressions@leemhuis.info, ndesaulniers@google.com, mike.kravetz@oracle.com, maskray@google.com, kirill.shutemov@linux.intel.com, irogers@google.com, hughd@google.com, hjl.tools@gmail.com, ckennelly@google.com, adobriyan@gmail.com, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 11/14] revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" Message-Id: <20220415021356.1B0B3C385A1@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Andrew Morton Subject: revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders") is an attempt to fix regressions due to 9630f0d60fec5f ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE"). But regressionss continue to be reported: https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/ https://bugzilla.kernel.org/show_bug.cgi?id=215720 https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info This patch reverts the fix, so the original can also be reverted. Fixes: 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders") Cc: H.J. Lu Cc: Chris Kennelly Cc: Al Viro Cc: Alexey Dobriyan Cc: Song Liu Cc: David Rientjes Cc: Ian Rogers Cc: Hugh Dickins Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Fangrui Song Cc: Nick Desaulniers Cc: Kirill A. Shutemov Cc: Mike Kravetz Cc: Shuah Khan Cc: Thorsten Leemhuis Cc: Mike Rapoport Cc: Signed-off-by: Andrew Morton --- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/binfmt_elf.c~revert-fs-binfmt_elf-fix-pt_load-p_align-values-for-loaders +++ a/fs/binfmt_elf.c @@ -1118,7 +1118,7 @@ out_free_interp: * without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); - if (interpreter || alignment > ELF_MIN_ALIGN) { + if (alignment > ELF_MIN_ALIGN) { load_bias = ELF_ET_DYN_BASE; if (current->flags & PF_RANDOMIZE) load_bias += arch_mmap_rnd(); From patchwork Fri Apr 15 02:13:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 563101 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E3DEC4332F for ; Fri, 15 Apr 2022 02:14:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348612AbiDOCQi (ORCPT ); Thu, 14 Apr 2022 22:16:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348615AbiDOCQh (ORCPT ); Thu, 14 Apr 2022 22:16:37 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F34D13190A; Thu, 14 Apr 2022 19:14:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AFF15B82BF3; Fri, 15 Apr 2022 02:14:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FCA3C385A5; Fri, 15 Apr 2022 02:13:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988839; bh=am2ji8hOArEj1jJvaTmG1u8UgrvozH1QixzKt+KNgWU=; h=Date:To:From:In-Reply-To:Subject:From; b=Fx/60ptRS88rycGMyNZZbzfrt/wpN4qFFZtmnPKZFN7XJXELZJfMo7nQX1RhMz6B/ PqCS64+RxvO+cwxBK3HDcZdY7BzYSJIaa+d58gHI0phEUln+4es3L0AhbvodPYcKl3 wWPrpoa1INiiohMDLVcOI0TdZdZ9BwMvI6UfkO54= Date: Thu, 14 Apr 2022 19:13:58 -0700 To: viro@zeniv.linux.org.uk, surenb@google.com, stable@vger.kernel.org, sspatil@google.com, songliubraving@fb.com, shuah@kernel.org, rppt@kernel.org, rientjes@google.com, regressions@leemhuis.info, ndesaulniers@google.com, mike.kravetz@oracle.com, maskray@google.com, kirill.shutemov@linux.intel.com, irogers@google.com, hughd@google.com, hjl.tools@gmail.com, ckennelly@google.com, adobriyan@gmail.com, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 12/14] revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" Message-Id: <20220415021359.3FCA3C385A5@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Andrew Morton Subject: revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" Despite Mike's attempted fix (925346c129da117122), regressions reports continue: https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/ https://bugzilla.kernel.org/show_bug.cgi?id=215720 https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info So revert this patch. Fixes: 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE") Cc: Alexey Dobriyan Cc: Al Viro Cc: Chris Kennelly Cc: David Rientjes Cc: Fangrui Song Cc: H.J. Lu Cc: Hugh Dickins Cc: Ian Rogers Cc: Kirill A. Shutemov Cc: Mike Kravetz Cc: Mike Rapoport Cc: Nick Desaulniers Cc: Sandeep Patil Cc: Shuah Khan Cc: Song Liu Cc: Suren Baghdasaryan Cc: Thorsten Leemhuis Cc: Signed-off-by: Andrew Morton --- fs/binfmt_elf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/binfmt_elf.c~revert-fs-binfmt_elf-use-pt_load-p_align-values-for-static-pie +++ a/fs/binfmt_elf.c @@ -1117,11 +1117,11 @@ out_free_interp: * independently randomized mmap region (0 load_bias * without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ - alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); - if (alignment > ELF_MIN_ALIGN) { + if (interpreter) { load_bias = ELF_ET_DYN_BASE; if (current->flags & PF_RANDOMIZE) load_bias += arch_mmap_rnd(); + alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum); if (alignment) load_bias &= ~(alignment - 1); elf_flags |= MAP_FIXED_NOREPLACE; From patchwork Fri Apr 15 02:14:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 562187 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93FFCC433FE for ; Fri, 15 Apr 2022 02:14:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348607AbiDOCQi (ORCPT ); Thu, 14 Apr 2022 22:16:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348622AbiDOCQh (ORCPT ); Thu, 14 Apr 2022 22:16:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B662B18AE; Thu, 14 Apr 2022 19:14:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 037AD621EB; Fri, 15 Apr 2022 02:14:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EBADC385A7; Fri, 15 Apr 2022 02:14:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649988845; bh=eBBWAnXrVUdhi6HB2GZp6T9EAQR1Og4UhicA+Umrp6E=; h=Date:To:From:In-Reply-To:Subject:From; b=k3qjibzzNtJShJVheS/MtFb3s5dnZMgNnC7Uvf9vgugDT+ZLPGgTOjdAntB9evZp0 HbtoPg/Wc/8mIXETw8DTz+kzj6w7RS9AwdVAYFXoBWLRB4A6NxSOJEC7XutmbN3UCt f1Lo4iLlZOEJm0rUWWUnOItXBggfRnsuzk9DFDQ0= Date: Thu, 14 Apr 2022 19:14:04 -0700 To: stable@vger.kernel.org, catalin.marinas@arm.com, patrick.wang.shcn@gmail.com, akpm@linux-foundation.org, patches@lists.linux.dev, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> Subject: [patch 14/14] mm: kmemleak: take a full lowmem check in kmemleak_*_phys() Message-Id: <20220415021405.5EBADC385A7@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Patrick Wang Subject: mm: kmemleak: take a full lowmem check in kmemleak_*_phys() The kmemleak_*_phys() apis do not check the address for lowmem's min boundary, while the caller may pass an address below lowmem, which will trigger an oops: # echo scan > /sys/kernel/debug/kmemleak [ 54.888353] Unable to handle kernel paging request at virtual address ff5fffffffe00000 [ 54.888932] Oops [#1] [ 54.889102] Modules linked in: [ 54.889326] CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33 [ 54.889620] Hardware name: riscv-virtio,qemu (DT) [ 54.889901] epc : scan_block+0x74/0x15c [ 54.890215] ra : scan_block+0x72/0x15c [ 54.890390] epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30 [ 54.890607] gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200 [ 54.890835] t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90 [ 54.891024] s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000 [ 54.891201] a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001 [ 54.891377] a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005 [ 54.891552] s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90 [ 54.891727] s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0 [ 54.891903] s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000 [ 54.892078] s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f [ 54.892271] t5 : 0000000000000001 t6 : 0000000000000000 [ 54.892408] status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d [ 54.892643] [] scan_gray_list+0x12e/0x1a6 [ 54.892824] [] kmemleak_scan+0x2aa/0x57e [ 54.892961] [] kmemleak_write+0x32a/0x40c [ 54.893096] [] full_proxy_write+0x56/0x82 [ 54.893235] [] vfs_write+0xa6/0x2a6 [ 54.893362] [] ksys_write+0x6c/0xe2 [ 54.893487] [] sys_write+0x22/0x2a [ 54.893609] [] ret_from_syscall+0x0/0x2 [ 54.894183] ---[ end trace 0000000000000000 ]--- The callers may not quite know the actual address they pass(e.g. from devicetree). So the kmemleak_*_phys() apis should guarantee the address they finally use is in lowmem range, so check the address for lowmem's min boundary. Link: https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.shcn@gmail.com Signed-off-by: Patrick Wang Acked-by: Catalin Marinas Cc: Signed-off-by: Andrew Morton --- mm/kmemleak.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/mm/kmemleak.c~mm-kmemleak-take-a-full-lowmem-check-in-kmemleak__phys +++ a/mm/kmemleak.c @@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan); void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int min_count, gfp_t gfp) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_alloc(__va(phys), size, min_count, gfp); } EXPORT_SYMBOL(kmemleak_alloc_phys); @@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys); */ void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_free_part(__va(phys), size); } EXPORT_SYMBOL(kmemleak_free_part_phys); @@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys); */ void __ref kmemleak_not_leak_phys(phys_addr_t phys) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_not_leak(__va(phys)); } EXPORT_SYMBOL(kmemleak_not_leak_phys); @@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys); */ void __ref kmemleak_ignore_phys(phys_addr_t phys) { - if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) + if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) kmemleak_ignore(__va(phys)); } EXPORT_SYMBOL(kmemleak_ignore_phys);