linux-kernel - Re: [RFC 1/2] lib/vsprintf: Add support for pte

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ca4d1ac9-725c-491f-b1ff-26661952557e@arm.com>
Date: Thu, 19 Jun 2025 15:23:37 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Pedro Falcato <pfalcato@...e.de>
Cc: linux-mm@...ck.org, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Rasmus Villemoes <linux@...musvillemoes.dk>,
 Sergey Senozhatsky <senozhatsky@...omium.org>, Petr Mladek
 <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>,
 Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...ux-foundation.org>,
 David Hildenbrand <david@...hat.com>, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org
Subject: Re: [RFC 1/2] lib/vsprintf: Add support for pte_t



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@...e.com>
>> Cc: Steven Rostedt <rostedt@...dmis.org>
>> Cc: Jonathan Corbet <corbet@....net>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: David Hildenbrand <david@...hat.com>
>> Cc: linux-doc@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org
>> Cc: linux-mm@...ck.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....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.