Re: [can-next] can: proc: remove pointers from CAN specific proc output

On 14.08.26 14:31, Sebastian Andrzej Siewior wrote:

On 2026-08-14 12:54:38 [+0200], Oliver Hartkopp wrote:
…

quoted

function names and sock inode numbers when available. As there's no known
tooling around the CAN specific proc output breaking the ABI with this
rework creates no issue.

I let you be the judge of that.

…

quoted

--- a/Documentation/networking/can.rst
+++ b/Documentation/networking/can.rst

@@ -1040,19 +1040,19 @@ As described in :ref:`socketcan-receive-lists` the SocketCAN core uses several f
  lists to deliver received CAN frames to CAN protocol modules. These
  receive lists, their filters and the count of filter matches can be
  checked in the appropriate receive list. All entries contain the
  device and a protocol module identifier::
  
-    foo@bar:~$ cat /proc/net/can/rcvlist_all
+    foo@bar:~$ cat /proc/net/can/rcvlist_fil

Is this _fil a typo?

No, it's a slightly different example.

quoted

-    receive list 'rx_all':
-      (vcan3: no entry)
-      (vcan2: no entry)
-      (vcan1: no entry)
-      device   can_id   can_mask  function  userdata   matches  ident
-       vcan0     000    00000000  f88e6370  f6c6f400         0  raw
+    receive list 'rx_fil':
        (any: no entry)
+      device   can_id   can_mask   matches     sock_inode     function
+       vcan0  80000123  c00007ff         0  000000000000f862  raw_rcv [can_raw]
+      (vcan1: no entry)
+      (vcan2: no entry)
+      (vcan3: no entry)
  
  In this example an application requests any CAN traffic from vcan0::
  
      rcvlist_all - list for unfiltered entries (no filter operations)
      rcvlist_eff - list for single extended frame (EFF) entries

…

quoted

--- a/net/can/bcm.c
+++ b/net/can/bcm.c

@@ -2039,11 +2038,11 @@ static int bcm_connect(struct socket *sock, struct sockaddr_unsized *uaddr, int
  	}
  
  #if IS_ENABLED(CONFIG_PROC_FS)
  	if (net->can.bcmproc_dir) {
  		/* unique socket address as filename */
-		sprintf(bo->procname, "%llu", sock_i_ino(sk));
+		sprintf(bo->procname, "%016llx", sock_i_ino(sk));

snprintf() would be a bit bulletproof

Will change that in v2

quoted

  		bo->bcm_proc_read = proc_create_net_single(bo->procname, 0644,
  						     net->can.bcmproc_dir,
  						     bcm_proc_show, sk);
  		if (!bo->bcm_proc_read) {
  			ret = -ENOMEM;

…

quoted

diff --git a/net/can/proc.c b/net/can/proc.c
index de4d05ae3459..b7858fb66178 100644
--- a/net/can/proc.c
+++ b/net/can/proc.c

@@ -189,30 +189,35 @@ static void can_print_rcvlist(struct seq_file *m, struct hlist_head *rx_list,
  			      struct net_device *dev)
  {
  	struct receiver *r;
  
  	hlist_for_each_entry_rcu(r, rx_list, list) {
-		char *fmt = (r->can_id & CAN_EFF_FLAG)?
-			"   %-5s  %08x  %08x  %pK  %pK  %8ld  %s\n" :
-			"   %-5s     %03x    %08x  %pK  %pK  %8ld  %s\n";
+		char *fmt;
  
+#if IS_ENABLED(CONFIG_KALLSYMS)

Please don't. I fix %ps and then there is no leak. There will be then
the 0 and everything will be fine.

I can wait for your changes before the v2 posting.

Btw. do you think "0" is a good return value, when people expect a 
function name?

What about "(unknown)" or something similar?

quoted

+		fmt = (r->can_id & CAN_EFF_FLAG)?
+			"  %6s  %08x  %08x  %8ld  %016llx  %ps\n" :
+			"  %6s     %03x    %08x  %8ld  %016llx  %ps\n";
  		seq_printf(m, fmt, DNAME(dev), r->can_id, r->mask,
-			   r->func, r->data, atomic_long_read(&r->matches),
-			   r->ident);
+			   atomic_long_read(&r->matches), r->ino, r->func);
+#else
+		fmt = (r->can_id & CAN_EFF_FLAG)?
+			"  %6s  %08x  %08x  %8ld  %016llx  (unknown)\n" :
+			"  %6s     %03x    %08x  %8ld  %016llx  (unknown)\n";
+		seq_printf(m, fmt, DNAME(dev), r->can_id, r->mask,
+			   atomic_long_read(&r->matches), r->ino);
+#endif
  	}
  }

…

So if you do this now, then I probably should remove that hunk from my
patch.

IMHO these /proc/net/can changes go far beyond replacing the pointer 
values with "0".

I hope the
Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
is ok for your attribution?!?

Best regards,
Oliver