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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-08-14 12:54:38 [+0200], Oliver Hartkopp wrote:
…
> 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.

…
> --- 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?

> -    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
…
> --- 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

>  		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;
…
> 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.

> +		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.

Sebastian