From: Wupeng Ma <mawupeng1@huawei.com>
To: <akpm@linux-foundation.org>, <mike.kravetz@oracle.com>,
<songmuchun@bytedance.com>
Cc: <mhocko@suse.com>, <osalvador@suse.de>, <catalin.marinas@arm.com>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<mawupeng1@huawei.com>
Subject: [PATCH -next 1/1] mm: hugetlb_vmemmap: Fix WARN_ON in vmemmap_remap_pte
Date: Tue, 25 Oct 2022 09:42:15 +0800 [thread overview]
Message-ID: <20221025014215.3466904-1-mawupeng1@huawei.com> (raw)
From: Ma Wupeng <mawupeng1@huawei.com>
Commit f41f2ed43ca5 ("mm: hugetlb: free the vmemmap pages associated with
each HugeTLB page") add vmemmap_remap_pte to remap the tail pages as
read-only to catch illegal write operation to the tail page.
However this will lead to WARN_ON in arm64 in __check_racy_pte_update()
since this may lead to dirty state cleaned. This check is introduced by
commit 2f4b829c625e ("arm64: Add support for hardware updates of the
access and dirty pte bits") and the initial check is as follow:
BUG_ON(pte_write(*ptep) && !pte_dirty(pte));
Since we do need to mark this pte as read-only to catch illegal write
operation to the tail pages, use set_pte to replace set_pte_at to bypass
this check.
The following shell command can be used to reproduce this WARN_ON in
6.1.0-rc1:
echo 1 > /proc/sys/vm/hugetlb_optimize_vmemmap
cat /proc/sys/vm/hugetlb_optimize_vmemmap
echo 1024 > /proc/sys/vm/nr_overcommit_hugepages
mkdir -p /root/hugetlb
mount none /root/hugetlb -t hugetlbfs
fallocate -l 2g /root/hugetlb/xx &
Here is the detail WARN_ON log:
------------[ cut here ]------------
__check_racy_pte_update: racy dirty state clearing: 0x0068000416899f03 -> 0x0060000416898f83
WARNING: CPU: 3 PID: 394 at arch/arm64/include/asm/pgtable.h:318 vmemmap_remap_pte+0x118/0x120
Modules linked in:
CPU: 3 PID: 394 Comm: fallocate Not tainted 6.1.0-rc1 #224
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
Call trace:
vmemmap_remap_pte+0x118/0x120
vmemmap_remap_range+0x30c/0x560
hugetlb_vmemmap_optimize+0x158/0x408
__prep_new_huge_page+0x24/0x150
prep_new_huge_page+0x30/0x60
alloc_fresh_huge_page+0x1c4/0x1e0
alloc_surplus_huge_page+0xa0/0x168
alloc_huge_page+0x264/0x5b8
hugetlbfs_fallocate+0x294/0x680
vfs_fallocate+0x12c/0x568
ksys_fallocate+0x50/0xa0
__arm64_sys_fallocate+0x28/0x38
invoke_syscall+0x4c/0x110
el0_svc_common.constprop.0+0x68/0x128
do_el0_svc+0x34/0xd0
el0_svc+0x48/0xb8
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x18c/0x190
---[ end trace 0000000000000000 ]---
Fixes: f41f2ed43ca5 ("mm: hugetlb: free the vmemmap pages associated with each HugeTLB page")
Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
---
mm/hugetlb_vmemmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index ba2a2596fb4e..cb056265c31e 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -249,7 +249,7 @@ static void vmemmap_remap_pte(pte_t *pte, unsigned long addr,
struct page *page = pte_page(*pte);
list_add_tail(&page->lru, walk->vmemmap_pages);
- set_pte_at(&init_mm, addr, pte, entry);
+ set_pte(pte, entry);
}
/*
--
2.25.1
next reply other threads:[~2022-10-25 1:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 1:42 Wupeng Ma [this message]
2022-10-25 6:36 ` [PATCH -next 1/1] mm: hugetlb_vmemmap: Fix WARN_ON in vmemmap_remap_pte Muchun Song
2022-10-26 3:01 ` mawupeng
2022-10-29 1:55 ` mawupeng
2022-11-01 9:56 ` Catalin Marinas
2022-10-26 5:06 ` Anshuman Khandual
2022-10-26 7:01 ` Muchun Song
2022-10-26 8:36 ` Anshuman Khandual
2022-10-26 8:53 ` Muchun Song
2022-10-27 10:50 ` Catalin Marinas
2022-10-28 2:45 ` Muchun Song
2022-10-28 15:53 ` Catalin Marinas
2022-11-01 9:29 ` Muchun Song
2022-10-27 1:42 ` mawupeng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221025014215.3466904-1-mawupeng1@huawei.com \
--to=mawupeng1@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=osalvador@suse.de \
--cc=songmuchun@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.