linux-kernel - Re: [PATCH] arm64/mm: Assert NR_BM_PUD_TABLES for bm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aV4xUe0A4zMhPxU0@J2N7QTR9R3>
Date: Wed, 7 Jan 2026 10:11:29 +0000
From: Mark Rutland <mark.rutland@....com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: Ryan Roberts <ryan.roberts@....com>,
	linux-arm-kernel@...ts.infradead.org,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/mm: Assert NR_BM_PUD_TABLES for bm_pud[]

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@....com>
> >> Cc: Will Deacon <will@...nel.org>
> >> Cc: linux-arm-kernel@...ts.infradead.org
> >> Cc: linux-kernel@...r.kernel.org
> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@....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.