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 BD1622135D7 for ; Tue, 17 Mar 2026 15:10:34 +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=1773760235; cv=none; b=m+zkWeGWtO0L7yUXTfcYmTQ+4qQ/pBsSGWTUt9cKa3hMR2AFqp8gXls+cQr+VNWYRVCDx1FDbcWHwGMwAJ3+YudBsVZd25ba/bP+nC9bpgWg7ZK6uiYDTLIBpoa65SC0SiDurB9Zn1wwBx0kTWRPbEOzCkGs094bNyrvfS5azg4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773760235; c=relaxed/simple; bh=UtXsDkshessYhY8dc9QBfq/VvwBnZR3Lm+yiEI5oBaM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XA5bmJBZuHcNBJQEi6xRuhxm0/IV+lN5dM/0yFDyYIsTowIXq94rIKngPAMdC1pFUSrUGRQXGo0vZgrojL9gvnlGbhPcwbq+8XHcqItDjOcvvAdqsK0ysR84MQY01Ousn+VfOfbMc5VFA1nYXlXtcqjwPVflwKy4V1CQhtLNj2E= 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 1C1841477; Tue, 17 Mar 2026 08:10:28 -0700 (PDT) Received: from [10.1.37.182] (unknown [10.1.37.182]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3CA823F778; Tue, 17 Mar 2026 08:10:33 -0700 (PDT) Message-ID: <50bf7259-50df-4bcc-b6f3-01a838de89ac@arm.com> Date: Tue, 17 Mar 2026 15:10:31 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm64: mm: Use generic enum pgtable_level Content-Language: en-GB To: Kevin Brodsky , "David Hildenbrand (Arm)" , linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon References: <20260316140150.58207-1-kevin.brodsky@arm.com> <415ea4a5-e729-4fe5-b95d-29fcca8f7dbd@arm.com> <132a27ae-4deb-401f-86ad-f8b496bfd778@arm.com> <672cdd3d-45ac-4e40-8b4d-6423ace14262@kernel.org> <361498f4-ccf2-4be1-be05-861b417499b5@arm.com> From: Ryan Roberts In-Reply-To: <361498f4-ccf2-4be1-be05-861b417499b5@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 17/03/2026 12:47, Kevin Brodsky wrote: > On 16/03/2026 15:45, David Hildenbrand (Arm) wrote: >> 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(). > > I don't think this would help, pgd_pgtable_alloc_init_mm() is passed > around as a function pointer so the compiler can't know the value of > pgtable_level at compile time. > >> VM_WARN_ON() >> >> might be good enough I guess. Fine by me. > > I think so, not calling a ctor at PGD level has no real consequence (it > wasn't done at all until recently). > > - Kevin