Re: [PATCH v8 3/4] rust: fmt: Default raw pointer formatting to HashedPtr

[Alice Ryhl <aliceryhl@google.com>]

On Tue, Jan 06, 2026 at 05:45:37PM +0100, Petr Mladek wrote:
> On Mon 2026-01-05 08:19:49, Alice Ryhl wrote:
> > On Fri, Jan 02, 2026 at 06:39:34PM +0100, Petr Mladek wrote:
> > > On Thu 2026-01-01 16:16:03, Ke Sun wrote:
> > > > Make raw pointers (*const T, *mut T) automatically use HashedPtr when
> > > > formatted with {:p}, providing safe default behavior for kernel pointers.
> > > >
> > > > This allows users to format raw pointers directly:
> > > >     pr_info!("{:p}\n", ptr);  // Automatically hashed
> > > 
> > > It should check no_hash_pointers variable, see default_pointer() in
> > > lib/vsprintf.c.  See also "no_hash_pointers" and "hash_pointers=never"
> > > kernel command line options.
> > > 
> > > Hashed pointers prevent leaking information but are not good for
> > > debugging. The "no_hash_pointers" variable allows to print
> > > raw pointers without changing the code.
> > > 
> > > I am not sure how this should be implemented in Rust. If you need
> > > to keep HashPtr then it should become an implementation detail
> > > and should not get exported. Nobody wants always hashed pointers.
> > > 
> > > I hope that we could find a better solution which would allow
> > > to reduce the code duplication.
> > > 
> > > For example, I wonder what would be needed to allow calling
> > > snprintf() from Rust code. The fn fmt() might call
> > > it with "%p" format...  It would make it easier to get
> > > also other "%p?" formats.
> > > 
> > > It seems that something similar has been discussed at
> > > https://lore.kernel.org/rust-for-linux/CALpAb9MoT20Ch4pe-oMz8kpqaZsvmgNwPk1XSC+faZi7huwQKg@mail.gmail.com/
> > > And it was said that it would need bigger changes.
> > > 
> > > Maybe, we could create C wrappers which would allow to call
> > > snprintf() with some specific format, e.g.
> > > 
> > > int scnprintf_p(char *buf, int size, const void *p)
> > > {
> > > 	return scnprintf(buf, size, "%p", p);
> > > }
> > > EXPORT_SYMBOL_NS_GPL(scnprintf_p, "RUST_INTERNAL");
> > > 
> > > And use the same approach for any other %p? format, e.g. for %pU:
> > > 
> > > int scnprintf_pU(char *buf, int size, const u8 *addr)
> > > {
> > > 	return scnprintf(buf, size, "%pU", addr);
> > > }
> > > EXPORT_SYMBOL_NS_GPL(scnprintf_pU, "RUST_INTERNAL");
> > > 
> > > Best Regards,
> > > Petr
> > > 
> > > PS: I suggest to wait longer before sending a new version. It would
> > >     allow to get feedback from more people who might see it from
> > >     different angles.
> > 
> > I think there are two approaches we could take:
> > 
> > 1. Have the C side provide a method that returns the correct integer
> >    address to print.
> > 2. Have the C side provide a method that returns the correct string
> >    to print.
> > 
> > In general, for cases where the output is an integer formatted in some
> > standard way (e.g. hex), I think the first option is stronger because
> > the Rust formatting machinery lets you specify different modifiers such
> > as "prefix with zeroes or spaces" or "how many zeroes/spaces to prefix
> > with" or "hex uppercase or lowercase" or "hex vs octal vs base10" etc.
> > By having the C side pass an integer back to Rust, these modifiers are
> > taken into account automatically.
> 
> Just to be sure that we are talking about the same things.
> 
> 1. C Code
> 
>    According to "man 3 printf", the C printf() allows to define the
>    format using the syntax:
> 
>      %[argument$][flags][width][.precision][length modifier]conversion
> 
>   , where for example:
> 
>      printf("%016llx\n", val);
> 
>    would printf zero padded hex value with a field width 16.
> 
> 
> 2. Rust code
> 
>    According to https://doc.rust-lang.org/std/fmt/ , Rust allows
>    the define the format using the syntax:
> 
>     format_spec := [[fill]align][sign]['#']['0'][width]['.' precision][type]
> 
>   It is actually more complicated. There are also traits, ...
> 
> 
> Now, I think that we are talking about three categories:
> 
>   a) Number and string formatting, in C, for example, %d, %x, %u, %s
>   b) Classic pointer value formatting, in C, %p
>   c) Kernel specific pointer formatting, in C, for example, %pK, %pe, %pS, %pI6
> 
> 
> My view:
> 
>   Ad a) IMHO, we do not need anything special for the number and string
> 	formatting. Rust code should use the native Rust formatting.
> 
>   Ad b) %p is handled quite special way in kernel:
> 
> 	+ hashed by default
> 	+ hashing disabled with "no_hash_pointers"
> 	+ special hashing of early code when "debug_boot_weak_hash"
> 	+ no hashing for IS_ERR_OR_NULL(ptr) values
> 	+ fallback to "(____ptrval____)" : "(ptrval)" before
> 	  random numbers are initialized enough
> 
>       I would try to avoid as much duplicity as possible.
>       IMHO, the current approach duplicates too much.
> 
>       This is why I suggested to add a wrapper for
>       scnprintf(buf, size, "%p", ptr) and call it from Rust.
> 
>       By other words, I think that this is close to the c) category
>       with all the kernel-specific pointer format modifiers. They
>       print the data at the pointer address a special way.

If I write this code in normal Rust:

	let ptr = &3 as *const i32;
	println!("{:?}", ptr);
	println!("{:017?}", ptr);
	println!("{:17?}", ptr);

it prints:

0x602ae0ec95d8
0x000602ae0ec95d8
   0x602ae0ec95d8

If we implement {:?} on a raw pointer type (and {:p} on reference type)
to use scnprintf with a stack buffer for the string representation, then
we lose this flexibility. (Or we need additional effort to pass through
the various ways you can configure it to scnprintf.)

>    Ad c) I am not sure how to handle all the kernel-specific %p?
> 	 modifiers in Rust.
> 
> 	I guess that it will be done by implementing "fn fmt"
> 	in a crate for the related pointer type. Or something like
> 	this.
> 
> 	Note that I have almost zero knowledge about Rust at the
> 	moment :-/

I mean, if we take the Mac address example, you would just have a Mac
address type, and when you print it, you get a Mac address. So I'm not
worried about that.

As for %pa and %pad we do not need special logic. The Rust formatting
machinery does not require specifying the type being printed in the fmt
string, so it doesn't matter if the integer is sometimes u32 and
sometimes u64. It will work in both cases.

Alice

> > Now, just using scnprintf to write the resulting string to a buffer and
> > passing that string into the Rust formatting machinery is also an option
> > of course. Especially for modifiers such as %pF that prints something
> > like versatile_init+0x0/0x110.
> 
> Yeah, I think that this might be a good option how to export
> the kernel-specific handling of the various %p?, formats,
> including plain %p, on the C side.
> 
> Best Regards,
> Petr