From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Kevin Brodsky <kevin.brodsky@arm.com>,
Ryan Roberts <ryan.roberts@arm.com>,
linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH] arm64: mm: Use generic enum pgtable_level
Date: Mon, 16 Mar 2026 15:45:19 +0100 [thread overview]
Message-ID: <672cdd3d-45ac-4e40-8b4d-6423ace14262@kernel.org> (raw)
In-Reply-To: <132a27ae-4deb-401f-86ad-f8b496bfd778@arm.com>
On 3/16/26 15:38, Kevin Brodsky wrote:
> On 16/03/2026 15:22, Ryan Roberts wrote:
>>> static phys_addr_t __pgd_pgtable_alloc(struct mm_struct *mm, gfp_t gfp,
>>> - enum pgtable_type pgtable_type)
>>> + enum pgtable_level pgtable_level)
>>> {
>>> /* Page is zeroed by init_clear_pgtable() so don't duplicate effort. */
>>> struct ptdesc *ptdesc = pagetable_alloc(gfp & ~__GFP_ZERO, 0);
>>> @@ -539,40 +539,42 @@ static phys_addr_t __pgd_pgtable_alloc(struct mm_struct *mm, gfp_t gfp,
>>>
>>> pa = page_to_phys(ptdesc_page(ptdesc));
>>>
>>> - switch (pgtable_type) {
>>> - case TABLE_PTE:
>>> + switch (pgtable_level) {
>>> + case PGTABLE_LEVEL_PTE:
>>> BUG_ON(!pagetable_pte_ctor(mm, ptdesc));
>>> break;
>>> - case TABLE_PMD:
>>> + case PGTABLE_LEVEL_PMD:
>>> BUG_ON(!pagetable_pmd_ctor(mm, ptdesc));
>>> break;
>>> - case TABLE_PUD:
>>> + case PGTABLE_LEVEL_PUD:
>>> pagetable_pud_ctor(ptdesc);
>>> break;
>>> - case TABLE_P4D:
>>> + case PGTABLE_LEVEL_P4D:
>>> pagetable_p4d_ctor(ptdesc);
>>> break;
>>> + default:
>>> + break;
>> nit: I think we should either explicitly support pgd or explicitly bug/warn. Now
>> that the enum has PGTABLE_LEVEL_PGD it looks legit to call __pgd_pgtable_alloc()
>> to allocate one. But it will currently silently fail to call pagetable_pgd_ctor().
>
> I hesitated there as well, eventually I concluded that we're dealing
> with kernel page tables so we'll never allocate a PGD anyway...
>
>> Probably simplest just to call BUG() in the default path?
>
> ... but that's certainly fine by me :)
If we could force it to be inline, we could turn it into a BUILD_BUG().
VM_WARN_ON()
might be good enough I guess.
--
Cheers,
David
next prev parent reply other threads:[~2026-03-16 14:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 14:01 [PATCH] arm64: mm: Use generic enum pgtable_level Kevin Brodsky
2026-03-16 14:07 ` David Hildenbrand (Arm)
2026-03-16 14:22 ` Ryan Roberts
2026-03-16 14:38 ` Kevin Brodsky
2026-03-16 14:45 ` David Hildenbrand (Arm) [this message]
2026-03-17 12:47 ` Kevin Brodsky
2026-03-17 15:10 ` Ryan Roberts
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=672cdd3d-45ac-4e40-8b4d-6423ace14262@kernel.org \
--to=david@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=will@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.