Re: [PATCH net-next] net: Convert %pK back to %p
Petr Mladek <[email protected]> Thu, 9 Jul 2026 13:28:36 +0200
| Newsgroups | org.kernel.vger.linux-sctp,org.kernel.vger.linux-can,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On Mon 2026-07-06 09:38:24, Sebastian Andrzej Siewior wrote:
> This is a revert of commit 71338aa7d050c ("net: convert %p usage to
> %pK") which is from 2011. Back then the default behaviour for %p was to
> print the pointer. The %pK modifier was introduced to be able to control
> the behaviour of specific pointer output without changing the behaviour
> of %p for everyone. It was dedicated to avoid leaking pointers via
> /proc.
> There was also the idea to remove the check from formatting the string
> and move to the open callback (of the /proc file) with some helpers but
> this did not happen.
>
> Things changed over time. The default behaviour for %p is now to print a
> hash pointer which does not leak the address but allows to
> correlate if two pointers are equal. The pointer to hash value mapping
> is not stable across reboots so one can not precompute the values and
> have a lookup table. There is also the `hash_pointers' boot argument
> which allows to disable it and print real pointers if needed. The
> default behaviour of %pK (kptr_restrict==0) is already %p (hashed
> pointer).
>
> The %pK modifier brings hardly and value over %p. Removing it allows to
> remove the policy checks from pointer formatting.
Yes, I believe that the %pK behavior has been obsoleted by hashing
pointers printed via %p by default and hash_pointers= boot parameter.
> My long term goal is remove the restricted_pointer() handling from
> vsprintf. I don't see any benefit in having it and case kptr_restrict==1
> caused problems in terms of locking. Instead of attempting to get the
> debug/ warn infrastructure right I am for removing it.
Yes, it would be nice because the locking is tricky.
Acked-by: Petr Mladek <[email protected]>
Best Regards,
Petr