From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 183A132B983 for ; Wed, 7 Jan 2026 10:11:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767780700; cv=none; b=VrQz8SKJB1Auwc/HKHj3cZ3pqYjbO1oeWdUf+Vs8jFlFfxWilpdgSkqZYi8rAkSN8ep6LS5+P6o/G2F2uwfyqSnM1yx9kUw+ibhxhwVBUG8+y1ae2JThADebNQh4PYv/j9mWtb530ipgCdmhqNjoHtMnM2Gk7MNlXL6DECUMXzI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767780700; c=relaxed/simple; bh=xGxPjMhT8AnTCxQO+Qa3UIf6Rhu0JNkOIAuFWg50hjI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C93vM8dbfxHszWj7Cddfm1vVlLhdcp82i6FgHcQXhCosLcHPLAJRYMyBCz3hEkbBX+L3B7Qrm6OAbemm0Gvc78eqJ7CyG2XqHOoqWEnsJTqBDWj6PnWnUXmmoEN2+vaSrK390Qc7O/IcqmVXrZZTompGHovlOMt00k2x/a5KDOI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 26362497; Wed, 7 Jan 2026 02:11:29 -0800 (PST) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 12D673F6A8; Wed, 7 Jan 2026 02:11:34 -0800 (PST) Date: Wed, 7 Jan 2026 10:11:29 +0000 From: Mark Rutland To: Anshuman Khandual Cc: Ryan Roberts , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/mm: Assert NR_BM_PUD_TABLES for bm_pud[] Message-ID: References: <20260107061606.3160088-1-anshuman.khandual@arm.com> <32030401-06d3-40ad-a0b6-fbd366092f2b@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > >> Cc: Will Deacon > >> Cc: linux-arm-kernel@lists.infradead.org > >> Cc: linux-kernel@vger.kernel.org > >> Signed-off-by: Anshuman Khandual > >> --- > >> 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.