Re: [PATCH V3] mm: Standardize printing for pgtable entries

[Andrew Morton]

On Fri, 10 Jul 2026 08:40:25 +0530 Anshuman Khandual <anshuman.khandual@xxxxxxx> wrote:

> 
> 
> On 10/07/26 5:38 AM, Andrew Morton wrote:
> > On Thu,  9 Jul 2026 10:13:34 +0530 Anshuman Khandual <anshuman.khandual@xxxxxxx> wrote:
> > 
> >> From: "David Hildenbrand (Arm)" <david@xxxxxxxxxx>
> >>
> >> Bad page map reporting currently stores page table entry values in an
> >> unsigned long long and prints them with fixed 64-bit-oriented format
> >> strings. This is inconsistent across call sites and does not work well for
> >> architectures where page table entry values are not naturally represented
> >> as 64-bit values, such as 32-bit or 128-bit entries.
> > 
> > Well grumble.  It's a lot of fuss for something which nobody is hurting
> > from.  Or are they?  What's the actual utility here?
> 
> Current page table entries print does not work here for
> 128 bits format (arm64 D128) because neither 'unsigned
> long long' can hold 128 bits nor printing extracts u64
> from the 128 bit entries while printing with "%llx".
> 
> Proposed a separate printk format %pp[te|md|ud|p4d|gd]
> 
> https://lore.kernel.org/all/20260610043545.3725735-1-anshuman.khandual@xxxxxxx/  
>  
> But there after it was decided to rather have a local
> solution in mm/memory.c instead of adding a new print
> format.

OK, thanks.  Let's please spell such things out in the changelogging. 
Explaining how a change helps our users (ie, improves Linux) is super
important!

> >>  	if (!pgd_present(*pgdp) || pgd_leaf(*pgdp)) {
> >> -		pr_alert("pgd:%08llx\n", pgdv);
> >> +		pr_alert("pgd:%s\n", pgd_str);
> > 
> > can this do
> > 		pr_alert("pgd:%s\n", ptval_to_str(pgd_str, pgd_val(*pgdp)));
> > 
> > and eliminate a few locals?
> 
> But that would not eliminate any local variable.
> 
> The helper ptval_to_str() does not return but instead
> fills up the provided buffer which later gets printed.

Well yes.  Changing it to return `buf' was kinda implicit!