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: <9f3fdc4f-2f44-4a3b-9b8b-425003b0be99@arm.com>
Date: Fri, 20 Jun 2025 11:30:47 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Petr Mladek <pmladek@...e.com>, Pedro Falcato <pfalcato@...e.de>
Cc: David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Rasmus Villemoes <linux@...musvillemoes.dk>,
 Sergey Senozhatsky <senozhatsky@...omium.org>,
 Steven Rostedt <rostedt@...dmis.org>, Jonathan Corbet <corbet@....net>,
 Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org
Subject: Re: [RFC 1/2] lib/vsprintf: Add support for pte_t



On 19/06/25 6:38 PM, Petr Mladek wrote:
> On Wed 2025-06-18 19:16:00, Pedro Falcato wrote:
>> On Wed, Jun 18, 2025 at 10:44:20AM +0200, David Hildenbrand wrote:
>>> On 18.06.25 10:37, Anshuman Khandual wrote:
>>>>
>>>>
>>>> On 18/06/25 1:48 PM, David Hildenbrand wrote:
>>>>> On 18.06.25 06:12, 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.
>>>>>
>>>>> Curious, why the decision to pass by reference?
>>>>
>>>> Just to make this via %p<> based address mechanism. But wondering
>>>> will it be better for the pte to be represented via value instead
>>>> of reference ?
>>>
>>> We commonly pass ptes to functions through value, not reference, that's why
>>> I am asking.
>>
>>
>> All printf/printk extensions in the kernel follow %p<some letters> and use
>> pointers because %p takes pointers, so it lets us use -Wformat with no issues.
>>
>> So yes, taking a pte_t * is required.
> 
> Correct. But the pointer is usually needed because the %pxx format
> need to access a structure.

Right.

> 
> Passing a pointer is another potential source of errors. I mean that
> the callers might pass an invalid pointer by mistake...

Agreed - could be a source of error when not used properly.

> 
> Another aspect is performance. It is likely not a big deal for classic
> printk() which is a slow path. But trace_printk() tries to optimize
> the speed by deferred formatting where possible, see vbin_printf()
> and bstr_printf().
> 
> I think that this is not a blocker for this patchset. But you should
> know that using %pxx has a cost.
Got it - thanks for the explanation.