Re: [PATCH] binder: Use %p for pointer formatting

[Carlos Llamas <cmllamas@google.com>]

On Fri, Sep 25, 2026 at 09:59:01AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-09-24 22:17:06 [+0000], Carlos Llamas wrote:
> > On Fri, Sep 18, 2026 at 12:30:08PM +0200, Sebastian Andrzej Siewior wrote:
> > > Commit 8ca86f1639ec5 ("binder: replace "%p" with "%pK"") introduced the
> > > %pK modifier in order not to leak kernel pointer.
> > > Since commit ad67b74d2469d ("printk: hash addresses printed with %p")
> > > pointers are hashed by default and the behaviour can be controller by
> > > `hash_pointers' boot argument.
> > > Commit 57483a362741e ("binder: Create safe versions of binder log
> > > files") introduced a hashed version while preserving the other interface
> > > where pointers are returned. This interface is for debugging of memory
> > > leaks. Ideally it would provide just one interface without leaking
> > > pointers.
> > 
> > These binder_log files is a different thing. These are userspace
> > pointers.
> 
> It looks like the reveal points, I wasn't aware that those are userspace
> pointers.
> 
> > > The policy on %p is to not introduce new ones. Rather then removing the
> > > pointer output make it use %p.
> > 
> > IIUC, the policy is to use %pK for seq_printf() files exposed to users.
> > This is the relevant section from printk-formats.rst:
> > 
> >  | If (and only if) you are printing addresses as a content of a virtual file in
> >  | e.g. procfs or sysfs (using e.g. seq_printf(), not printk()) read by a
> >  | userspace process, use the %pK modifier described below instead of %p or %px.
> > 
> > Has this changed?
> 
> I am working on getting rid of %pK.

Oh, I see. That makes sense. Nice!

> 
> > > 
> > > Cc: Tiffany Y. Yang <ynaffit@google.com>
> > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > > ---
> > >  drivers/android/binder.c | 4 ++--
> > 
> > This file is now deleted anyway.
> 
> And with it the %pK usage?

Yeah, it's all gone now:
https://git.kernel.org/gregkh/char-misc/c/fd2bc059ed46

--
Carlos Llamas