Re: [PATCH net-next] net: Convert %pK back to %p
Sebastian Andrzej Siewior <[email protected]> Tue, 14 Jul 2026 17:09:57 +0200
| Newsgroups | org.kernel.vger.linux-sctp,org.kernel.vger.linux-can,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
tl;dr: Do the networking folks mind switch it to 0 instead the pointer?
On 2026-07-09 09:18:44 [-0700], Kees Cook wrote:
> On Mon, Jul 06, 2026 at 09:38:24AM +0200, 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.
>
> Given the policy on bare %p, and that there are so few in this list (15
> files), how about review those that can just simply be removed or
> switched to %pS, etc:
> https://docs.kernel.org/process/deprecated.html#p-format-specifier
It is not a new use, but an old one ;)
The pointers are data pointers of sockets and so on, not code. So using
%pS will reveal the exact pointers even with hashing enabled (in case
you think about changing the behaviour for __sprint_symbol() for cases
where kallsyms fails to resolve the symbol).
The things here are "reports" such as /proc/net/icmp where you get
|# cat /proc/net/icmp
| sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
| 53: 00000000:C9F2 00000000:0000 07 00000000:00000000 00:00000000 00000000 1000 0 4569 2 000000001145b7f6 0
so this is probably considered as ABI. lsof, lsfd (util-linux) are using
this file. So I don't think this entry can be removed. These kind of
files have usually a flexible ABI and are fine with adding new
attributes but not removing existing ones.
In this cases we usually put 0 if we remove an entry.
The pointer in icmp has been added int commit c319b4d76b9e5 ("net: ipv4:
add IPPROTO_ICMP socket kind") and no explanation why. But the order is
the same as in the tcp or raw file. I traced the tcp pointer inclusion
back to 2.3.15pre3 with no explanation. It just appeared with bunch of
other changes so maybe making debug a bit easier.
Anyway, given all this, do the networking folks mind switch it to 0
instead the pointer?
Sebastian