Re: [PATCH RESEND v13 2/2] rust: fmt: route {:p} through HashedPtr to prevent address leaks

On 8/5/26 16:15, Alice Ryhl wrote:
> On Mon, Jul 06, 2026 at 01:18:44PM +0800, Ke Sun wrote:
>> Define a custom `kernel::fmt::Pointer` trait and `HashedPtr` wrapper
>> so that `{:p}` formatting uses the kernel's `%p` hashed format instead
>> of printing raw pointer values, preventing kernel address space leaks.
>>
>> Signed-off-by: Ke Sun <[email protected]>
> Overall looks good to me, but one thing:
>
>> +impl<T: ?Sized> Pointer for HashedPtr<T> {
>> +    fn fmt(&self, f: &mut Formatter<'_>) -> Result {
>> +        use crate::str::CStrExt as _;
>> +
>> +        let mut buf = [0u8; 32];
>> +
>> +        // SAFETY: `buf` is a valid, writable buffer of 32 bytes, sufficient for all architectures
>> +        // (max 19 bytes for 64-bit). The format string `c"0x%p"` is null-terminated and `%p`
>> +        // matches the pointer argument.
>> +        let len = unsafe {
>> +            crate::bindings::scnprintf(
>> +                buf.as_mut_ptr().cast(),
>> +                buf.len(),
>> +                // Rust's `{:p}` includes a "0x" prefix, the kernel's `%p` does not.
>> +                c"0x%p".as_char_ptr(),
>> +                self.0.cast::<core::ffi::c_void>(),
>> +            )
>> +        };
> When given a null pointer, this will print 0x(null), which seems a bit
> weird. It may also print 0x(ptrval) or 0x(____ptrval____) during early
> boot.

Thanks to Gary's suggestion, `%#p` in v14 adds the "0x" prefix for
normal pointers but leaves placeholder tokens like "(____ptrval____)"
untouched.

Best regards,
Alvin

>
> It seems like it'd be nice to special-case these to provide better
> output in those cases.
>
> Alice
>