Re: [RFC 1/2] lib/vsprintf: Add support for pte_t

[Anshuman Khandual <anshuman.khandual@arm.com>]

On 18/06/25 11:49 PM, Pedro Falcato wrote:
> On Wed, Jun 18, 2025 at 09:42:34AM +0530, Anshuman Khandual wrote:
>> Add a new format for printing page table entries.
>>
>> Cc: Petr Mladek <pmladek@suse.com>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@redhat.com>
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-mm@kvack.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>  Documentation/core-api/printk-formats.rst | 14 ++++++++++++++
>>  lib/vsprintf.c                            | 20 ++++++++++++++++++++
>>  mm/memory.c                               |  5 ++---
>>  scripts/checkpatch.pl                     |  2 +-
>>  4 files changed, 37 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
>> index 4b7f3646ec6ce..75a110b059ee1 100644
>> --- a/Documentation/core-api/printk-formats.rst
>> +++ b/Documentation/core-api/printk-formats.rst
>> @@ -689,6 +689,20 @@ Rust
>>  Only intended to be used from Rust code to format ``core::fmt::Arguments``.
>>  Do *not* use it from C.
>>  
>> +Page Table Entry
>> +----------------
>> +
>> +::
>> +        %ppte
>> +
>> +Print standard page table entry pte_t.
>> +
>> +Passed by reference.
>> +
>> +Examples for a 64 bit page table entry, given &(u64)0xc0ffee::
>> +
>> +        %ppte   0x00c0ffee
> 
> Ok, so what's the point of this if you're just printing the number?

I might have got this wrong probably. The ideas is to represent
a 64 bit address containing a 64 bit value i.e 0xc0ffee - which
needs to be printed via the new print format.

> 
> Could at least do something like:
> 
> %ppte 0xc0ff000|WRITE|DIRTY|PRESENT
> 
> no? Otherwise it's a not super useful wrapper around printing pte_val(*pte).

Although it would be great to have PTE flags called out as well,
the proposed patch here just wanted to transparently extract 64
bit printable value from pte_t represented page table entries.

But coming back to your suggestion above.

%ppte 0xc0ff000|WRITE|DIRTY|PRESENT

Should all the generic page table entry flags and contained pfn
be extracted from the pte_t and printed via new format %ppte ?

> 
>> +
>>  Thanks
>>  ======
>>  
>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>> index 3d85800757aa5..005490202ffb5 100644
>> --- a/lib/vsprintf.c
>> +++ b/lib/vsprintf.c
>> @@ -2433,6 +2433,9 @@ early_param("no_hash_pointers", no_hash_pointers_enable);
>>   *		Without an option prints the full name of the node
>>   *		f full name
>>   *		P node name, including a possible unit address
>> + * - 'pte'	For a 64 bit page table entry, this prints its contents in
>> + *              a hexa decimal format
>> + *
>>   * - 'x' For printing the address unmodified. Equivalent to "%lx".
>>   *       Please read the documentation (path below) before using!
>>   * - '[ku]s' For a BPF/tracing related format specifier, e.g. used out of
>> @@ -2542,6 +2545,23 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
>>  		default:
>>  			return error_string(buf, end, "(einval)", spec);
>>  		}
>> +	case 'p':
>> +		if (fmt[1] == 't' && fmt[2] == 'e') {
>> +			pte_t *pte = (pte_t *)ptr;
>> +
>> +			spec.field_width = 10;
>> +			spec.precision = 8;
>> +			spec.base = 16;
>> +			spec.flags = SPECIAL | SMALL | ZEROPAD;
>> +			if (sizeof(pte_t) == sizeof(u64)) {
>> +				u64 val = pte_val(*pte);
>> +
>> +				return number(buf, end, val, spec);
>> +			}
> 
> As mentioned elsewhere in the thread, this obviously doesn't work for everything
> 32-bit, and 64-bit PAE, and all of the weird page table formats we have around.
I will accommodate 32 bit formats.

But what about 64-bit PAE ? Would not pte_val() also return a printable
64 bit number for such cases. Could you please elaborate on the weird
page table formats you mentioned and why would not pte_val() work for
those as well.