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: <aFqCmgT1k8daroNZ@pathway.suse.cz>
Date: Tue, 24 Jun 2025 12:48:58 +0200
From: Petr Mladek <pmladek@...e.com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: 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>,
	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 Fri 2025-06-20 13:32:31, Anshuman Khandual wrote:
> On 19/06/25 7:31 PM, Petr Mladek wrote:
> > On Wed 2025-06-18 09:42:34, Anshuman Khandual wrote:
> >> Add a new format for printing page table entries.
> > 
> > How many users do you explect, please?
> > 
> > This patch adds only one caller. It does not justify the added complexity.
> 
> Understood.
> 
> The idea is to convert all page table entry prints through out the tree
> both in generic and platform code. Added just a single generic example
> here for this being a RFC proposal. Will go through similar instances
> and be back with more comprehensive change set.

You do not need to cover all cases at this stage. For me it is enough
to know that the printf format will have several (like >= 5) users.

> >> @@ -2542,6 +2545,23 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
[...]
> Agreed. Andy also might have suggested about special_hex_number() helper
> on the other thread. Will try and use the helper instead.
> 
> > 
> >> +			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);
> >> +			}
> >> +			WARN_ONCE(1, "Non standard pte_t\n");
> > 
> > This is nasty. It should be a compile-time check. And the code should
> 
> Something like BUILD_BUG_ON() against pte_t as either u64 or u32 aka all
> the sizes the print format is going to support and it should pass on all
> platforms ?

Yes, I had BUILD_BUG_ON() in mind. It would be nice if you check at
least the most known architectures. You could do it just by looking
into the code. We could rely on the bots, monitoring mailing list
and linux-next, for the less known architectures.

The more you check in advance the less surprises would come
from the bots.

Best Regards,
Petr