Re: [PATCH v2 4/6] mm: drop HIGHPTE support altogether

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/12/26 14:26, Arnd Bergmann wrote:
> On Thu, Nov 12, 2026, at 12:54, Mike Rapoport wrote:
>> On Thu, Nov 12, 2026 at 12:25:26PM +0100, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>
>>> With both x86 and arm having dropped CONFIG_HIGHPTE support, no
>>> architecture is left using it, so remove the remnants in common code.
>>>
>>> It is likely that further cleanups are possible in the page table
>>> code but those are not obvious from the config options.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>>  include/linux/hugetlb.h | 5 +----
>>>  include/linux/mm.h      | 1 -
>>>  include/linux/pgtable.h | 9 ---------
>>>  3 files changed, 1 insertion(+), 14 deletions(-)
>>
>> With this and arm HIGHPTE patches applied there are still a few leftovers:
>>
>> $ git grep  HIGHPTE
>> arch/arm/configs/vt8500_v6_v7_defconfig:CONFIG_HIGHPTE=y
> 
> This got dropped in patch 5/6 in v2, but I've moved that here now.
> 
>> mm/memory.c:     * Dumping the PTE would be nice, but it's tricky with 
>> CONFIG_HIGHPTE,
> 
> Added the patch below for this. Untested so far.
> 
>> mm/pgtable-generic.c: * kmapped if necessary (when CONFIG_HIGHPTE), and 
>> locked against concurrent
> 
> Updated the comment and also dropped __pte_map() after I noticed that
> open-coding the only caller in pte_offset_map_rw_nolock() is consistent
> with that comment change:
> 
> --- a/mm/pgtable-generic.c
> +++ b/mm/pgtable-generic.c
> @@ -314,7 +314,7 @@ pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp)
>                 pmd_clear_bad(pmd);
>                 goto nomap;
>         }
> -       return __pte_map(&pmdval, addr);
> +       return pte_offset_kernel(&pmdval, addr);
>  nomap:
>         rcu_read_unlock();
>         return NULL;
> 
> 
>> mm/userfaultfd.c:        * index ordering when CONFIG_HIGHPTE is 
>> enabled. We mapped dst_pte
> 
> Dropped that comment block as it no longer applies.
> 
>> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> 
> Thanks,
> 
>       Arnd
> ---
> Subject: [PATCH] mm: print pte in __print_bad_page_map_pgtable()
> 
> HIGHPTE support is gone now, so it's easy enough to print the
> PTE here along with the upper level entries.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index ec3d9d99ccee..dabeb5568c94 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -528,9 +528,11 @@ static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long add
>  	char p4d_str[PTVAL_STR_MAX];
>  	char pud_str[PTVAL_STR_MAX];
>  	char pmd_str[PTVAL_STR_MAX];
> +	char pte_str[PTVAL_STR_MAX];
>  	p4d_t p4d, *p4dp;
>  	pud_t pud, *pudp;
>  	pmd_t pmd, *pmdp;
> +	pte_t pte, *ptep;
>  	pgd_t *pgdp;
>  
>  	/*
> @@ -567,13 +569,18 @@ static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long add
>  	pmd = pmdp_get(pmdp);
>  	ptval_to_str(pmd_str, pmd_val(pmd));
>  
> -	/*
> -	 * Dumping the PTE would be nice, but it's tricky with CONFIG_HIGHPTE,
> -	 * because the table should already be mapped by the caller and
> -	 * doing another map would be bad. print_bad_page_map() should
> -	 * already take care of printing the PTE.
> -	 */
> -	pr_alert("pgd:%s p4d:%s pud:%s pmd:%s\n", pgd_str, p4d_str, pud_str, pmd_str);
> +	if (!pmd_present(pmd) || pmd_leaf(pmd)) {
> +		pr_alert("pgd:%s p4d:%s pud:%s pmd: %s\n",
> +			 pgd_str, p4d_str, pud_str, pmd_str);
> +		return;
> +	}
> +
> +	ptep = pte_offset_kernel(pmdp, addr);
> +	pte = ptep_get(ptep);
> +	ptval_to_str(pte_str, pte_val(pte));
> +
> +	pr_alert("pgd:%s p4d:%s pud:%s pmd:%s pte:%s\n",
> +		 pgd_str, p4d_str, pud_str, pmd_str, pte_str);
>  }
>  
>  /*

Yeah, that LGTM. I assume you'll send out a v3.

-- 
Cheers,

David