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

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 <[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.

I’ve also seen a bunch of 0x(ptrval) during testing.

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!

Tested-by: Link Mauve <[email protected]>

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

-- 
Link Mauve