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

[Alvin Sun <alvin.sun@linux.dev>]

On 8/6/26 22:24, Link Mauve wrote:
> On Wed, Aug 05, 2026 at 08:15:06AM +0000, 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 <sunke@kylinos.cn>
>> 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.
> I’ve also seen a bunch of 0x(ptrval) during testing.

Same `0x(ptrval)` issue — also addressed in v14.

>
> This series resolves a mystery where I thought I was crazy since
> addresses of pointers and references were never what I thought they
> were, and instead were always on the stack, thanks a lot for resolving
> this!

I was just as confused — spent quite a while debugging before
realizing `{:p}` was the culprit. I'll send v14 shortly, would
be great if you could give it another spin.

>
> Tested-by: Link Mauve <linkmauve@linkmauve.fr>

Thanks for testing!

Best regards,
Alvin

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