From: Muchun Song <muchun.song@linux.dev>
To: "Björn Töpel" <bjorn@kernel.org>
Cc: Muchun Song <songmuchun@bytedance.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
stable@vger.kernel.org, david@kernel.org, osalvador@suse.de,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, x86@kernel.org, hpa@zytor.com,
catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
linux-arm-kernel@lists.infradead.org, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
linux-riscv@lists.infradead.org, agordeev@linux.ibm.com,
kevin.brodsky@arm.com, bjorn@rivosinc.com, apopple@nvidia.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] riscv/mm: fix hotplug page-table destructor handling
Date: Fri, 9 Oct 2026 22:14:40 +0800 [thread overview]
Message-ID: <0E3A4E15-38DA-400D-95F2-01FFBB36304B@linux.dev> (raw)
In-Reply-To: <87jynrs8v8.fsf@all.your.base.are.belong.to.us>
> On Oct 9, 2026, at 14:09, Björn Töpel <bjorn@kernel.org> wrote:
>
> Muchun Song <songmuchun@bytedance.com> writes:
>
>> RISC-V uses the same memory-hotplug teardown code for the linear map and
>> vmemmap, although their page-table pages are not always allocated in the
>> same way. Late linear-map allocations run page-table constructors, while
>> vmemmap and early allocations may provide constructor-free pages.
>>
>> The PTE path unconditionally runs the destructor, which is wrong for
>> constructor-free vmemmap tables. The PMD path avoids that problem by
>> using is_vmemmap as a proxy for constructor state, but that assumption
>> will no longer hold once runtime vmemmap allocations use the normal
>> pgalloc helpers.
>>
>> Page-table constructors record their state in PG_table. Centralize
>> page-table freeing and use PageTable() to decide whether the destructor
>> is required. Keep reserved and constructor-free pages on their existing
>> freeing paths.
>>
>> Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support")
>> Cc: stable@vger.kernel.org
>> Assisted-by: LLM
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> ---
>> arch/riscv/mm/init.c | 29 ++++++++++++++---------------
>> 1 file changed, 14 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> index 857f9a55039c..429a0b015ec1 100644
>> --- a/arch/riscv/mm/init.c
>> +++ b/arch/riscv/mm/init.c
>> @@ -1486,10 +1486,19 @@ struct execmem_info __init *execmem_arch_setup(void)
>> #endif /* CONFIG_EXECMEM */
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>> +static void __meminit free_pagetable(struct page *page)
>> +{
>> + if (PageReserved(page))
>> + free_reserved_page(page);
>> + else if (PageTable(page))
>> + pagetable_dtor_free(page_ptdesc(page));
>> + else
>> + pagetable_free(page_ptdesc(page));
>> +}
>
> Is PageReserved() enought to determine if there's no dtor to run? On
Yes.
> rv64 your code is correct, but maybe for robustness?
>
> | if (PageTable(page))
> | pagetable_dtor(page_ptdesc(page));
> |
> | if (PageReserved(page))
> | free_reserved_page(page);
> | else
> | pagetable_free(page_ptdesc(page));
his looks good to me as well. I'll change it in the next version. Thanks!
Muchun
>
>
> Björn
WARNING: multiple messages have this Message-ID (diff)
From: Muchun Song <muchun.song@linux.dev>
To: "Björn Töpel" <bjorn@kernel.org>
Cc: Muchun Song <songmuchun@bytedance.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
stable@vger.kernel.org, david@kernel.org, osalvador@suse.de,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, x86@kernel.org, hpa@zytor.com,
catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
linux-arm-kernel@lists.infradead.org, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
linux-riscv@lists.infradead.org, agordeev@linux.ibm.com,
kevin.brodsky@arm.com, bjorn@rivosinc.com, apopple@nvidia.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] riscv/mm: fix hotplug page-table destructor handling
Date: Fri, 9 Oct 2026 22:14:40 +0800 [thread overview]
Message-ID: <0E3A4E15-38DA-400D-95F2-01FFBB36304B@linux.dev> (raw)
In-Reply-To: <87jynrs8v8.fsf@all.your.base.are.belong.to.us>
> On Oct 9, 2026, at 14:09, Björn Töpel <bjorn@kernel.org> wrote:
>
> Muchun Song <songmuchun@bytedance.com> writes:
>
>> RISC-V uses the same memory-hotplug teardown code for the linear map and
>> vmemmap, although their page-table pages are not always allocated in the
>> same way. Late linear-map allocations run page-table constructors, while
>> vmemmap and early allocations may provide constructor-free pages.
>>
>> The PTE path unconditionally runs the destructor, which is wrong for
>> constructor-free vmemmap tables. The PMD path avoids that problem by
>> using is_vmemmap as a proxy for constructor state, but that assumption
>> will no longer hold once runtime vmemmap allocations use the normal
>> pgalloc helpers.
>>
>> Page-table constructors record their state in PG_table. Centralize
>> page-table freeing and use PageTable() to decide whether the destructor
>> is required. Keep reserved and constructor-free pages on their existing
>> freeing paths.
>>
>> Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support")
>> Cc: stable@vger.kernel.org
>> Assisted-by: LLM
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> ---
>> arch/riscv/mm/init.c | 29 ++++++++++++++---------------
>> 1 file changed, 14 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> index 857f9a55039c..429a0b015ec1 100644
>> --- a/arch/riscv/mm/init.c
>> +++ b/arch/riscv/mm/init.c
>> @@ -1486,10 +1486,19 @@ struct execmem_info __init *execmem_arch_setup(void)
>> #endif /* CONFIG_EXECMEM */
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>> +static void __meminit free_pagetable(struct page *page)
>> +{
>> + if (PageReserved(page))
>> + free_reserved_page(page);
>> + else if (PageTable(page))
>> + pagetable_dtor_free(page_ptdesc(page));
>> + else
>> + pagetable_free(page_ptdesc(page));
>> +}
>
> Is PageReserved() enought to determine if there's no dtor to run? On
Yes.
> rv64 your code is correct, but maybe for robustness?
>
> | if (PageTable(page))
> | pagetable_dtor(page_ptdesc(page));
> |
> | if (PageReserved(page))
> | free_reserved_page(page);
> | else
> | pagetable_free(page_ptdesc(page));
his looks good to me as well. I'll change it in the next version. Thanks!
Muchun
>
>
> Björn
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-10-09 14:15 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 7:30 [PATCH 0/4] mm: Fix page-table teardown during memory hot-remove Muchun Song
2026-10-08 7:30 ` Muchun Song
2026-10-08 7:30 ` [PATCH 1/4] x86/mm: fix missing pgtable destructor for vmemmap tables Muchun Song
2026-10-08 7:30 ` Muchun Song
2026-10-08 8:32 ` Muchun Song
2026-10-08 8:32 ` Muchun Song
2026-10-09 20:29 ` David Hildenbrand (Arm)
2026-10-09 20:29 ` David Hildenbrand (Arm)
2026-10-10 3:44 ` Muchun Song
2026-10-10 3:44 ` Muchun Song
2026-10-09 20:33 ` David Hildenbrand (Arm)
2026-10-09 20:33 ` David Hildenbrand (Arm)
2026-10-09 20:36 ` David Hildenbrand (Arm)
2026-10-09 20:36 ` David Hildenbrand (Arm)
2026-10-10 3:49 ` Muchun Song
2026-10-10 3:49 ` Muchun Song
2026-10-09 20:54 ` Dave Hansen
2026-10-09 20:54 ` Dave Hansen
2026-10-10 5:11 ` Muchun Song
2026-10-10 5:11 ` Muchun Song
2026-10-08 7:30 ` [PATCH 2/4] riscv/mm: fix hotplug page-table destructor handling Muchun Song
2026-10-08 7:30 ` Muchun Song
2026-10-09 6:09 ` Björn Töpel
2026-10-09 6:09 ` Björn Töpel
2026-10-09 14:14 ` Muchun Song [this message]
2026-10-09 14:14 ` Muchun Song
2026-10-09 20:37 ` David Hildenbrand (Arm)
2026-10-09 20:37 ` David Hildenbrand (Arm)
2026-10-10 2:58 ` Muchun Song
2026-10-10 2:58 ` Muchun Song
2026-10-10 12:27 ` David Hildenbrand (Arm)
2026-10-10 12:27 ` David Hildenbrand (Arm)
2026-10-08 7:30 ` [PATCH 3/4] riscv/mm: fix missing destructor for hotplug PUD tables Muchun Song
2026-10-08 7:30 ` Muchun Song
2026-10-09 20:38 ` David Hildenbrand (Arm)
2026-10-09 20:38 ` David Hildenbrand (Arm)
2026-10-08 7:30 ` [PATCH 4/4] arm64/mm: fix destructor for unconstructed hotplug page tables Muchun Song
2026-10-08 7:30 ` Muchun Song
2026-10-09 20:43 ` David Hildenbrand (Arm)
2026-10-09 20:43 ` David Hildenbrand (Arm)
2026-10-10 3:43 ` Muchun Song
2026-10-10 3:43 ` Muchun Song
2026-10-09 20:48 ` [PATCH 0/4] mm: Fix page-table teardown during memory hot-remove Dave Hansen
2026-10-09 20:48 ` Dave Hansen
2026-10-10 9:42 ` Muchun Song
2026-10-10 9:42 ` Muchun Song
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=0E3A4E15-38DA-400D-95F2-01FFBB36304B@linux.dev \
--to=muchun.song@linux.dev \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=apopple@nvidia.com \
--cc=bjorn@kernel.org \
--cc=bjorn@rivosinc.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=osalvador@suse.de \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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.