Re: [net-next,real,v4] net: Replace %pK output with 0

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 1

- [Medium] Incomplete conversion relative to the commit's stated scope:
  after this patch net/ still contains %pK socket/object-pointer output.
- [Low] The updated /proc/net/tcp example in
  Documentation/networking/proc_net_tcp.rst does not match the…

--

net: Replace %pK output with 0

This replaces the %pK pointer output in the various /proc/net seq_file
printers with a literal 0, adjusting field spacing and header strings so
the column layout stays intact. Documentation/networking/proc_net_tcp.rst
is updated to describe the field as always 0.

net: Replace %pK output with 0

[ ... ]

    Replace the %pK annotation with 0 value. Correct the spacing for the
    cases where pointer is at the beginning.

[Severity: Medium]
The subject and this sentence read as if net/ no longer emits pointers,
but three files under net/ still use %pK after this commit:

  net/bluetooth/af_bluetooth.c:bt_seq_show()
	seq_printf(seq,
		   "%pK %-6d %-6u %-6u %-6u %-6llu %-6llu",
		   sk,

  net/can/proc.c:can_print_rcvlist()
	char *fmt = (r->can_id & CAN_EFF_FLAG)?
		"   %-5s  %08x  %08x  %pK  %pK  %8ld  %s\n" :
		"   %-5s     %03x    %08x  %pK  %pK  %8ld  %s\n";

  net/can/bcm.c:bcm_proc_show()
	seq_printf(m, ">>> socket %pK", sk->sk_socket);
	seq_printf(m, " / sk %pK", sk);
	seq_printf(m, " / bo %pK", bo);

bt_seq_show() is installed by bt_procfs_init() for every Bluetooth
protocol, so /proc/net/l2cap, /proc/net/sco, /proc/net/rfcomm*,
/proc/net/hci*, /proc/net/iso, /proc/net/bnep and /proc/net/hidp keep
printing the struct sock pointer.

The changelog below the '---' line says the CAN changes were dropped on
purpose, but that text is discarded when the patch is applied, and the
Bluetooth site is not mentioned at all. Could the commit message name the
remaining sites so git log does not suggest net/ was fully converted?

[Severity: Low]
Does the example still match what the kernel prints? The example shows two
spaces on each side of the new always-zero field, while get_tcp4_sock() in
net/ipv4/tcp_ipv4.c and get_tcp6_sock() in net/ipv6/tcp_ipv6.c both emit a
single space on each side:

	"%08X %5u %8d %llu %d 0 %lu %lu %u %u %d"

so the real line is:

   1000        0 54165785 4 0 25 4 27 3 -1

Should the example (and the arrow alignment below it) use the single-space
spacing, or should the format strings pad the field if the wider column is
intended?

+    |          |    |     |  |  |  | |  | |-------> slow start size threshold,
+    |          |    |     |  |  |  | |  |           or -1 if the threshold
+    |          |    |     |  |  |  | |  |           is >= 0xFFFF
+    |          |    |     |  |  |  | |  |---------> sending congestion window
+    |          |    |     |  |  |  | |------------> (ack.quick<<1)|ack.pingpong
+    |          |    |     |  |  |  |--------------> Predicted tick of soft clock
+    |          |    |     |  |  |                   (delayed ACK control data)
+    |          |    |     |  |  |-----------------> retransmit timeout
+    |          |    |     |  |--------------------> always 0 (was memory location).
     |          |    |     |-----------------------> socket reference count
     |          |    |-----------------------------> inode
     |          |----------------------------------> unanswered 0-window probes

[ ... ]

[ ... ]

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901160345.eeknHmY2%40linutronix.de