Re: [PATCH net-next 0/11] pull-request: can-next 2026-10-22

[Paolo Abeni <pabeni@redhat.com>]

On 10/22/26 13:19, Oliver Hartkopp wrote:
> On 22.10.26 10:37, Paolo Abeni wrote:
>> On 10/22/26 01:07, Marc Kleine-Budde wrote:
>>> Hello netdev-team,
>>>
>>> this is a pull request of 11 patches for net-next/main and obsoletes
>>> pull-request: linux-can-next-for-7.4-20261021.
>>>
>>> The first patch is by Vincent Mailhol and drops CAN-XL frames on non
>>> CAN-XL devices.
>>>
>>> A patch by Sang-Heon Jeon removes a redundant NULL check before
>>> netdev_hold() in the CAN RAW protocol.
>>>
>>> A patch by Kaixuan Li for the CAN ISOTP protocol improves the check
>>> for the correct CAN CC/FD frames.
>>>
>>> The next 3 patches are by Cunhao Lu and make CAN skb freeing safe in
>>> any context in several CAN helper functions.
>>>
>>> A series by Oliver Hartkopp et al fixes several problems in the CAN
>>> net-layer:
>>>
>>> 3 patches target the CAN procfs: A patch by Runyu Xiao resets the CAN
>>> pkg_stats using atomics, a patch by Oliver Hartkopp fixes the stats
>>> calculation after a statistics reset. Followed by a patch to remove
>>> kernel pointers from the output.
>>>
>>> The last 2 patches are by Oliver Hartkopp as well, they convert the
>>> unreliable ARPHRD_CAN type check to the robust can_get_ml_priv() and
>>> protect the CAN receive lists with a per-device lock.
>> I'm wrapping-up the net-next PR right now, and this will not make the
>> cut. Still all the material here, after forwarding the trees post PR,
>> looks like 'net' worthy. We could merge it afterwards.
> 
> Thanks Paolo!
> 
> Yes the patches are indeed mostly 'net' worthy fixes.
> 
> Unfortunately sashiko-bot complained about something new in my patch 11/11 and suggests to move some release_sock() calls 4 lines down behind sk_error_report(sk) :-/

Talking about the obsoleted version, right?
> Would you like to have that re-spin PR to be named as "net" PR ?
> And when would it be best to be sent?
No need to respin just for changing the prefix tag, we can apply
this one to net as needed. Generally speaking we are trying to
avoid unneeded reposting to avoid nipa resources overloading.

Thanks,

Paolo