Message ID | 20221121073608.4183459-1-liushixin2@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1422110wrr; Sun, 20 Nov 2022 22:51:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf6e8an0rZOnw7m5gMsUSC3iOGn0HdlimLPVlaKzQPT+pHXyyWqVpGZUtKsMbMEUITHMI+ih X-Received: by 2002:a05:6a00:2352:b0:572:91c6:9e4e with SMTP id j18-20020a056a00235200b0057291c69e4emr2355693pfj.53.1669013500421; Sun, 20 Nov 2022 22:51:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669013500; cv=none; d=google.com; s=arc-20160816; b=i+NfD8r03N/Yn2c+CrKy1MFPMn8tK9NnNhGw4nJ0d9sFSXTZ3whqBFgoCB48VrmaV5 dETbjMA2Zlo7QFjrT6RU+Ix2n0x3tJpJzpKxHJBAg2lNjpPONPWX1x4m39hXXYPPWKG5 CJkEFigKDCpK3nUBjtdiRl0x88keBsSKzfk/zultt3YJgNzFU7MEmofZW3mctudPv1aG xOZr58vUTUU73rpX9GylbIqVd6PxdGwW3ktRLkFctI2wZ07I3Ai2NOfxvZL2clQiXueK iOhEXnn6u8lYyEVdXkIGI98iGikws0RFS0Q1DzAqwWnBFlahTBRrhpQOnk9bNJkYl7O5 TCBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=w1Lr/Ew79sJzeOQw5QZBFZSLqFgX0VODxnRsE8UgmcI=; b=n0a+j+kuofHoSl/SAJXimKzVfld6A2Xg+ZlBw4sJ9gx4Zjm2SgSCdMFEJ7zvhd7ZdF 0MNuiL8YstEu6QOrydccKR6rXpYudkRm6Q7UzXYgADYzXlQch9QgtiuGlMkmQ09Wa9BI iT8isVb7cx/Yb8nJ6CFPdb8yOdSZmFcPBlTRdNC/yPvzGfUpZxbJlA/z/K7j192gr+Qx yDxhZfjP2fxD4JlWJ8/R9/c7Wp/9hpmicD1UU85gV8gneRx0/DsYqKgmhCOrtMCCzt96 iloRYA4WxI0Zb3ms67bh1zpGQ1JygVku21nUbegkW91UlectRHIJy+2dW9SRv5UY+1ZI BwXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y10-20020a170902caca00b00182d9015d42si9072224pld.225.2022.11.20.22.51.26; Sun, 20 Nov 2022 22:51:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229644AbiKUGsw (ORCPT <rfc822;peter110.wang@gmail.com> + 99 others); Mon, 21 Nov 2022 01:48:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229817AbiKUGsq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 21 Nov 2022 01:48:46 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E45D21B1D7 for <linux-kernel@vger.kernel.org>; Sun, 20 Nov 2022 22:48:41 -0800 (PST) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NFydK44NnzHw20; Mon, 21 Nov 2022 14:48:05 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 21 Nov 2022 14:48:40 +0800 Received: from huawei.com (10.175.113.32) by dggpemm100009.china.huawei.com (7.185.36.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 21 Nov 2022 14:48:39 +0800 From: Liu Shixin <liushixin2@huawei.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Denys Vlasenko <dvlasenk@redhat.com>, Kefeng Wang <wangkefeng.wang@huawei.com>, Anshuman Khandual <anshuman.khandual@arm.com>, David Hildenbrand <dhildenb@redhat.com>, Rafael Aquini <raquini@redhat.com>, Pasha Tatashin <pasha.tatashin@soleen.com> CC: <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, Liu Shixin <liushixin2@huawei.com> Subject: [PATCH v3] arm64/mm: fix incorrect file_map_count for invalid pmd Date: Mon, 21 Nov 2022 15:36:08 +0800 Message-ID: <20221121073608.4183459-1-liushixin2@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.113.32] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm100009.china.huawei.com (7.185.36.113) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750087499760187029?= X-GMAIL-MSGID: =?utf-8?q?1750087499760187029?= |
Series |
[v3] arm64/mm: fix incorrect file_map_count for invalid pmd
|
|
Commit Message
Liu Shixin
Nov. 21, 2022, 7:36 a.m. UTC
The page table check trigger BUG_ON() unexpectedly when split hugepage: ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:119! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748 Hardware name: linux,dummy-virt (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_set.isra.0+0x398/0x468 lr : page_table_check_set.isra.0+0x1c0/0x468 [...] Call trace: page_table_check_set.isra.0+0x398/0x468 __page_table_check_pte_set+0x160/0x1c0 __split_huge_pmd_locked+0x900/0x1648 __split_huge_pmd+0x28c/0x3b8 unmap_page_range+0x428/0x858 unmap_single_vma+0xf4/0x1c8 zap_page_range+0x2b0/0x410 madvise_vma_behavior+0xc44/0xe78 do_madvise+0x280/0x698 __arm64_sys_madvise+0x90/0xe8 invoke_syscall.constprop.0+0xdc/0x1d8 do_el0_svc+0xf4/0x3f8 el0_svc+0x58/0x120 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x19c/0x1a0 [...] On arm64, pmd_leaf() will return true even if the pmd is invalid due to pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count will not only decrease once but also increase once. Then in set_pte_at(), the file_map_count increase again, and so trigger BUG_ON() unexpectedly. Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the problem. Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") Reported-by: Denys Vlasenko <dvlasenk@redhat.com> Signed-off-by: Liu Shixin <liushixin2@huawei.com> Acked-by: Pasha Tatashin <pasha.tatashin@soleen.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- v1->v2: Update comment and optimize the code by moving p?d_valid() at first place suggested by Mark. v2->v3: Replace pmd_valid() with pmd_present_invalid() suggested by Will. arch/arm64/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, Nov 21, 2022 at 03:36:08PM +0800, Liu Shixin wrote: > The page table check trigger BUG_ON() unexpectedly when split hugepage: > > ------------[ cut here ]------------ > kernel BUG at mm/page_table_check.c:119! > Internal error: Oops - BUG: 00000000f2000800 [#1] SMP > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in: > CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748 > Hardware name: linux,dummy-virt (DT) > pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : page_table_check_set.isra.0+0x398/0x468 > lr : page_table_check_set.isra.0+0x1c0/0x468 > [...] > Call trace: > page_table_check_set.isra.0+0x398/0x468 > __page_table_check_pte_set+0x160/0x1c0 > __split_huge_pmd_locked+0x900/0x1648 > __split_huge_pmd+0x28c/0x3b8 > unmap_page_range+0x428/0x858 > unmap_single_vma+0xf4/0x1c8 > zap_page_range+0x2b0/0x410 > madvise_vma_behavior+0xc44/0xe78 > do_madvise+0x280/0x698 > __arm64_sys_madvise+0x90/0xe8 > invoke_syscall.constprop.0+0xdc/0x1d8 > do_el0_svc+0xf4/0x3f8 > el0_svc+0x58/0x120 > el0t_64_sync_handler+0xb8/0xc0 > el0t_64_sync+0x19c/0x1a0 > [...] > > On arm64, pmd_leaf() will return true even if the pmd is invalid due to > pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count > will not only decrease once but also increase once. Then in set_pte_at(), > the file_map_count increase again, and so trigger BUG_ON() unexpectedly. > > Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the > problem. > > Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") > Reported-by: Denys Vlasenko <dvlasenk@redhat.com> > Signed-off-by: Liu Shixin <liushixin2@huawei.com> > Acked-by: Pasha Tatashin <pasha.tatashin@soleen.com> > Acked-by: David Hildenbrand <david@redhat.com> > Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > v1->v2: Update comment and optimize the code by moving p?d_valid() at > first place suggested by Mark. > v2->v3: Replace pmd_valid() with pmd_present_invalid() suggested by Will. > > arch/arm64/include/asm/pgtable.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index edf6625ce965..17afb09f386f 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -863,7 +863,7 @@ static inline bool pte_user_accessible_page(pte_t pte) > > static inline bool pmd_user_accessible_page(pmd_t pmd) > { > - return pmd_leaf(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); > + return pmd_leaf(pmd) && !pmd_present_invalid(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); > } Acked-by: Will Deacon <will@kernel.org> But please see my comment on v2 about pud_user_exec() for the PUD case. Will
On 11/21/22 19:18, Will Deacon wrote: > On Mon, Nov 21, 2022 at 03:36:08PM +0800, Liu Shixin wrote: >> The page table check trigger BUG_ON() unexpectedly when split hugepage: >> >> ------------[ cut here ]------------ >> kernel BUG at mm/page_table_check.c:119! >> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP >> Dumping ftrace buffer: >> (ftrace buffer empty) >> Modules linked in: >> CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748 >> Hardware name: linux,dummy-virt (DT) >> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) >> pc : page_table_check_set.isra.0+0x398/0x468 >> lr : page_table_check_set.isra.0+0x1c0/0x468 >> [...] >> Call trace: >> page_table_check_set.isra.0+0x398/0x468 >> __page_table_check_pte_set+0x160/0x1c0 >> __split_huge_pmd_locked+0x900/0x1648 >> __split_huge_pmd+0x28c/0x3b8 >> unmap_page_range+0x428/0x858 >> unmap_single_vma+0xf4/0x1c8 >> zap_page_range+0x2b0/0x410 >> madvise_vma_behavior+0xc44/0xe78 >> do_madvise+0x280/0x698 >> __arm64_sys_madvise+0x90/0xe8 >> invoke_syscall.constprop.0+0xdc/0x1d8 >> do_el0_svc+0xf4/0x3f8 >> el0_svc+0x58/0x120 >> el0t_64_sync_handler+0xb8/0xc0 >> el0t_64_sync+0x19c/0x1a0 >> [...] >> >> On arm64, pmd_leaf() will return true even if the pmd is invalid due to >> pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count >> will not only decrease once but also increase once. Then in set_pte_at(), >> the file_map_count increase again, and so trigger BUG_ON() unexpectedly. >> >> Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the >> problem. >> >> Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") >> Reported-by: Denys Vlasenko <dvlasenk@redhat.com> >> Signed-off-by: Liu Shixin <liushixin2@huawei.com> >> Acked-by: Pasha Tatashin <pasha.tatashin@soleen.com> >> Acked-by: David Hildenbrand <david@redhat.com> >> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> >> --- >> v1->v2: Update comment and optimize the code by moving p?d_valid() at >> first place suggested by Mark. >> v2->v3: Replace pmd_valid() with pmd_present_invalid() suggested by Will. >> >> arch/arm64/include/asm/pgtable.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index edf6625ce965..17afb09f386f 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -863,7 +863,7 @@ static inline bool pte_user_accessible_page(pte_t pte) >> >> static inline bool pmd_user_accessible_page(pmd_t pmd) >> { >> - return pmd_leaf(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); >> + return pmd_leaf(pmd) && !pmd_present_invalid(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); >> } > > Acked-by: Will Deacon <will@kernel.org> > > But please see my comment on v2 about pud_user_exec() for the PUD case. Can you be more specific? Do you ask for pud_user_exec() to be defined and used here? Or something else? Until this patch lands, amd64 PAGE_TABLE_CHECK + THP remains broken...
On Mon, Nov 28, 2022 at 05:26:14PM +0100, Denys Vlasenko wrote: > On 11/21/22 19:18, Will Deacon wrote: > > On Mon, Nov 21, 2022 at 03:36:08PM +0800, Liu Shixin wrote: > > > The page table check trigger BUG_ON() unexpectedly when split hugepage: > > > > > > ------------[ cut here ]------------ > > > kernel BUG at mm/page_table_check.c:119! > > > Internal error: Oops - BUG: 00000000f2000800 [#1] SMP > > > Dumping ftrace buffer: > > > (ftrace buffer empty) > > > Modules linked in: > > > CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748 > > > Hardware name: linux,dummy-virt (DT) > > > pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > pc : page_table_check_set.isra.0+0x398/0x468 > > > lr : page_table_check_set.isra.0+0x1c0/0x468 > > > [...] > > > Call trace: > > > page_table_check_set.isra.0+0x398/0x468 > > > __page_table_check_pte_set+0x160/0x1c0 > > > __split_huge_pmd_locked+0x900/0x1648 > > > __split_huge_pmd+0x28c/0x3b8 > > > unmap_page_range+0x428/0x858 > > > unmap_single_vma+0xf4/0x1c8 > > > zap_page_range+0x2b0/0x410 > > > madvise_vma_behavior+0xc44/0xe78 > > > do_madvise+0x280/0x698 > > > __arm64_sys_madvise+0x90/0xe8 > > > invoke_syscall.constprop.0+0xdc/0x1d8 > > > do_el0_svc+0xf4/0x3f8 > > > el0_svc+0x58/0x120 > > > el0t_64_sync_handler+0xb8/0xc0 > > > el0t_64_sync+0x19c/0x1a0 > > > [...] > > > > > > On arm64, pmd_leaf() will return true even if the pmd is invalid due to > > > pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count > > > will not only decrease once but also increase once. Then in set_pte_at(), > > > the file_map_count increase again, and so trigger BUG_ON() unexpectedly. > > > > > > Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the > > > problem. > > > > > > Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") > > > Reported-by: Denys Vlasenko <dvlasenk@redhat.com> > > > Signed-off-by: Liu Shixin <liushixin2@huawei.com> > > > Acked-by: Pasha Tatashin <pasha.tatashin@soleen.com> > > > Acked-by: David Hildenbrand <david@redhat.com> > > > Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> > > > --- > > > v1->v2: Update comment and optimize the code by moving p?d_valid() at > > > first place suggested by Mark. > > > v2->v3: Replace pmd_valid() with pmd_present_invalid() suggested by Will. > > > > > > arch/arm64/include/asm/pgtable.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > > > index edf6625ce965..17afb09f386f 100644 > > > --- a/arch/arm64/include/asm/pgtable.h > > > +++ b/arch/arm64/include/asm/pgtable.h > > > @@ -863,7 +863,7 @@ static inline bool pte_user_accessible_page(pte_t pte) > > > static inline bool pmd_user_accessible_page(pmd_t pmd) > > > { > > > - return pmd_leaf(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); > > > + return pmd_leaf(pmd) && !pmd_present_invalid(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); > > > } > > > > Acked-by: Will Deacon <will@kernel.org> > > > > But please see my comment on v2 about pud_user_exec() for the PUD case. > > Can you be more specific? Do you ask for pud_user_exec() to be defined > and used here? Or something else? So we now have three patches, all from Liu, that are tripping over each other: 1. 5b47348fc0b1 ("arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud") Merged upstream in -rc6 2. This patch ("arm64/mm: fix incorrect file_map_count for invalid pmd") This could land for -rc8 (I acked it), but I'd be more comfortable queuing it at -rc1 seeing it as it isn't a recent regression, it explodes in the page-table check code and it will conflict with (1). 3. https://lore.kernel.org/r/20221122123137.429686-1-liushixin2@huawei.com ("arm64/mm: add pud_user_exec() check in pud_user_accessible_page()") This was just found by inspection, so it can definitely wait for next time (i.e. 6.3). > Until this patch lands, arm64 PAGE_TABLE_CHECK + THP remains broken... It's unfortunate, but I don't think it's new breakage and it's failing a synthetic check so it's hard to justify squeezing it in this late. Will
On Mon, 21 Nov 2022 15:36:08 +0800, Liu Shixin wrote: > The page table check trigger BUG_ON() unexpectedly when split hugepage: > > ------------[ cut here ]------------ > kernel BUG at mm/page_table_check.c:119! > Internal error: Oops - BUG: 00000000f2000800 [#1] SMP > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in: > CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748 > Hardware name: linux,dummy-virt (DT) > pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : page_table_check_set.isra.0+0x398/0x468 > lr : page_table_check_set.isra.0+0x1c0/0x468 > [...] > Call trace: > page_table_check_set.isra.0+0x398/0x468 > __page_table_check_pte_set+0x160/0x1c0 > __split_huge_pmd_locked+0x900/0x1648 > __split_huge_pmd+0x28c/0x3b8 > unmap_page_range+0x428/0x858 > unmap_single_vma+0xf4/0x1c8 > zap_page_range+0x2b0/0x410 > madvise_vma_behavior+0xc44/0xe78 > do_madvise+0x280/0x698 > __arm64_sys_madvise+0x90/0xe8 > invoke_syscall.constprop.0+0xdc/0x1d8 > do_el0_svc+0xf4/0x3f8 > el0_svc+0x58/0x120 > el0t_64_sync_handler+0xb8/0xc0 > el0t_64_sync+0x19c/0x1a0 > [...] > > [...] Applied to arm64 (for-next/fixes), thanks! [1/1] arm64/mm: fix incorrect file_map_count for invalid pmd https://git.kernel.org/arm64/c/74c2f8105451 Cheers,
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h index edf6625ce965..17afb09f386f 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -863,7 +863,7 @@ static inline bool pte_user_accessible_page(pte_t pte) static inline bool pmd_user_accessible_page(pmd_t pmd) { - return pmd_leaf(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); + return pmd_leaf(pmd) && !pmd_present_invalid(pmd) && (pmd_user(pmd) || pmd_user_exec(pmd)); } static inline bool pud_user_accessible_page(pud_t pud)