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@xxxxxxxx>
>> Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>
>> Cc: Jonathan Corbet <corbet@xxxxxxx>
>> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> Cc: David Hildenbrand <david@xxxxxxxxxx>
>> Cc: linux-doc@xxxxxxxxxxxxxxx
>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>> Cc: linux-mm@xxxxxxxxx
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@xxxxxxx>
>> ---
>> 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.
