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

On 14.08.26 15:52, Sebastian Andrzej Siewior wrote:
> 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.

Yep. Thanks!