From: Mike Rapoport <rppt@kernel.org>
To: Muchun Song <muchun.song@linux.dev>
Cc: Muchun Song <songmuchun@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
linux-mm@kvack.org, Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
Date: Thu, 9 Apr 2026 13:44:11 +0300 [thread overview]
Message-ID: <adeC--_dkgWHdSPj@kernel.org> (raw)
In-Reply-To: <D0D4B0DA-56F3-4ECD-8855-96C21A6DE1F0@linux.dev>
On Sun, Apr 05, 2026 at 10:07:36PM +0800, Muchun Song wrote:
> > On Apr 5, 2026, at 15:07, Mike Rapoport <rppt@kernel.org> wrote:
> > On Sat, Apr 04, 2026 at 08:20:54PM +0800, Muchun Song wrote:
> >> The two weak functions are currently no-ops on every architecture,
> >> forcing each platform that needs them to duplicate the same handful
> >> of lines. Provide a generic implementation:
> >>
> >> - vmemmap_set_pmd() simply sets a huge PMD with PAGE_KERNEL protection.
> >>
> >> - vmemmap_check_pmd() verifies that the PMD is present and leaf,
> >> then calls the existing vmemmap_verify() helper.
> >>
> >> Architectures that need special handling can continue to override the
> >> weak symbols; everyone else gets the standard version for free.
> >>
> >> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> >> ---
> >> mm/sparse-vmemmap.c | 7 ++++++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> >> index 6eadb9d116e4..1eb990610d50 100644
> >> --- a/mm/sparse-vmemmap.c
> >> +++ b/mm/sparse-vmemmap.c
> >> @@ -391,12 +391,17 @@ int __meminit vmemmap_populate_hvo(unsigned long addr, unsigned long end,
> >> void __weak __meminit vmemmap_set_pmd(pmd_t *pmd, void *p, int node,
> >> unsigned long addr, unsigned long next)
> >> {
> >> + BUG_ON(!pmd_set_huge(pmd, virt_to_phys(p), PAGE_KERNEL));
> >
> > Do we have to crash the kernel here?
> > Wouldn't be better to make vmemmap_set_pmd() return error and make
> > vmemmap_populate_hugepages() fall back to base pages in case
> > vmemmap_set_pmd() errored?
>
> Hi Mike,
>
> Thanks for the review. Let me explain my original thought process here.
>
> My assumption was that pmd_set_huge() for the kernel virtual address space
> should rarely, if ever, fail in this context. Furthermore, if we look at the
> architectures this patch replaces (e.g., arm64 and riscv), they are either
> ignoring the return value of pmd_set_huge() entirely or lacking any graceful
> fallback mechanism anyway.
>
> So, to keep the initial generic implementation as simple as possible, I used
> BUG_ON() as a strict assertion.
Fair enough, let's just make it VM_BUG_ON().
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-04-09 10:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-04 12:20 [PATCH v2 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd() Muchun Song
2026-04-04 12:20 ` Muchun Song
2026-04-04 12:20 ` [PATCH v2 1/5] " Muchun Song
2026-04-05 7:07 ` Mike Rapoport
2026-04-05 14:07 ` Muchun Song
2026-04-09 10:44 ` Mike Rapoport [this message]
2026-04-24 12:29 ` David Hildenbrand (Arm)
2026-04-04 12:20 ` [PATCH v2 2/5] arm64/mm: drop vmemmap_pmd helpers and use generic code Muchun Song
2026-05-18 12:33 ` Will Deacon
2026-05-19 6:15 ` Muchun Song
2026-04-04 12:20 ` [PATCH v2 3/5] riscv/mm: " Muchun Song
2026-04-04 12:20 ` Muchun Song
2026-04-04 12:20 ` [PATCH v2 4/5] loongarch/mm: drop vmemmap_check_pmd helper " Muchun Song
2026-04-04 12:20 ` [PATCH v2 5/5] sparc/mm: " 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=adeC--_dkgWHdSPj@kernel.org \
--to=rppt@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=songmuchun@bytedance.com \
--cc=surenb@google.com \
--cc=vbabka@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.