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

[Ke Sun <sk.alvin.x@gmail.com>]

On 1/5/26 16:19, 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.
>
> 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.
Thank you for the suggestion. I'm exploring this approach.

I previously implemented a version using snprintf, but found that C's %p 
format specifier
doesn't integrate well with Rust's formatting infrastructure.

Best Regards,
Ke Sun
> Alice