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

[Petr Mladek <pmladek@suse.com>]

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.


   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 :-/

> 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