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

On 2026-08-14 15:36:03 [+0200], Oliver Hartkopp wrote:
> > > --- 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.
okay then.

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

Yeah, that '(unknown)' looks slightly better.

> > > +		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 <[email protected]>
> is ok for your attribution?!?

That is fine. I just mean I should drop that hunk and repost to avoid
the pointless collision here.

> Best regards,
> Oliver

Sebastian