All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.