From: Mark Rutland <mark.rutland@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/mm: Assert NR_BM_PUD_TABLES for bm_pud[]
Date: Wed, 7 Jan 2026 10:11:29 +0000 [thread overview]
Message-ID: <aV4xUe0A4zMhPxU0@J2N7QTR9R3> (raw)
In-Reply-To: <32030401-06d3-40ad-a0b6-fbd366092f2b@arm.com>
On Wed, Jan 07, 2026 at 02:37:51PM +0530, Anshuman Khandual wrote:
>
>
> On 07/01/26 2:03 PM, Ryan Roberts wrote:
> > On 07/01/2026 06:16, Anshuman Khandual wrote:
> >> There is an implicit assumption about bm_pud[] being single entry PUD table
> >> just like bp_pmd[] which is a single entry PMD table. Though only the later
> >> gets asserted via NR_BM_PMD_TABLES. Hence let's add a similar check for PUD
> >> table as well.
> >>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: Will Deacon <will@kernel.org>
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> >> ---
> >> arch/arm64/mm/fixmap.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
> >> index c5c5425791da..e02594be8b8e 100644
> >> --- a/arch/arm64/mm/fixmap.c
> >> +++ b/arch/arm64/mm/fixmap.c
> >> @@ -23,8 +23,11 @@ static_assert(FIXADDR_TOT_START > PCI_IO_END);
> >> SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PMD_SHIFT)
> >> #define NR_BM_PMD_TABLES \
> >> SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PUD_SHIFT)
> >> +#define NR_BM_PUD_TABLES \
> >> + SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, P4D_SHIFT)
> >>
> >> static_assert(NR_BM_PMD_TABLES == 1);
> >> +static_assert(NR_BM_PUD_TABLES == 1);
> >
> > But if there is only one PMD table, there must only be one PUD table (and one
> > P4D table, and one PGD table) by definition. So I don't think this is checking
> > anything that the existing PMD table check is not.
>
> Agreed but should not this check help tighten this code up given that bm_pud[]
> array gets used for possible PUD entries ?
An assert isn't going to help with code generation, so this patch alone is not
useful. When I last looked at actually ommiting the table in various
configurations, it was more trouble than it was worth.
As Ryan said, we deliberately only added the assert for the PMD level,
and it's sufficient as-is. That happened in commit:
414c109bdf49 ("arm64: mm: always map fixmap at page granularity")
... where the commit message said:
Our VA layout means that the fixmap will always fall within a single PMD
table (and consequently, within a single PUD/P4D/PGD entry), which we
can verify at compile time with a static_assert(). With that assert a
number of runtime warnings become impossible, and are removed.
Please leave this as-is.
Mark.
next prev parent reply other threads:[~2026-01-07 10:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 6:16 Anshuman Khandual
2026-01-07 8:33 ` Ryan Roberts
2026-01-07 9:07 ` Anshuman Khandual
2026-01-07 9:13 ` Ryan Roberts
2026-01-07 10:11 ` Mark Rutland [this message]
2026-01-08 4:04 ` Anshuman Khandual
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=aV4xUe0A4zMhPxU0@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®