kernel/linux.git/drivers/net/can/vxcan.c, branch v6.2

rtnetlink: pass netlink message header and portid to rtnl_configure_link()

2022-11-01T01:10:21+00:00

This patch pass netlink message header and portid to rtnl_configure_link() All the functions in this call chain need to add the parameters so we can use them in the last call rtnl_notify(), and notify the userspace about the new link info if NLM_F_ECHO flag is set. - rtnl_configure_link() - __dev_notify_flags() - rtmsg_ifinfo() - rtmsg_ifinfo_event() - rtmsg_ifinfo_build_skb() - rtmsg_ifinfo_send() - rtnl_notify() Also move __dev_notify_flags() declaration to net/core/dev.h, as Jakub suggested. Signed-off-by: Hangbin Liu Reviewed-by: Guillaume Nault Signed-off-by: Jakub Kicinski

can: dev: add CAN XL support to virtual CAN

2022-09-15T07:08:09+00:00

Make use of new can_skb_get_data_len() helper. Add support for variable CANXL MTU using the new can_is_canxl_dev_mtu(). Acked-by: Vincent Mailhol Signed-off-by: Oliver Hartkopp Link: https://lore.kernel.org/all/20220912170725.120748-7-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde

can: tree-wide: advertise software timestamping capabilities

2022-07-28T09:44:01+00:00

Currently, some CAN drivers support hardware timestamping, some do not. But userland has no method to query which features are supported (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertised what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). This patch only targets the CAN drivers which *do not* support hardware timestamping. For each of those CAN drivers, implement the get_ts_info() using the generic ethtool_op_get_ts_info(). This way, userland can do: | $ ethtool --show-time-stamping canX to confirm the device timestamping capacities. N.B. the drivers which support hardware timestamping will be migrated in separate patches. Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/all/20220727101641.198847-6-mailhol.vincent@wanadoo.fr [mkl: mscan: add missing mscan_ethtool_ops] Signed-off-by: Marc Kleine-Budde

can: v(x)can: add software tx timestamps

2022-07-28T07:30:36+00:00

TX timestamps were added to the can_put_echo_skb() function of can_dev modules in [1]. However, vcan and vxcan do not rely on that function and as such do not offer TX timestamping. While it could be arguable whether TX timestamps are really needed for virtual interfaces, we prefer to still add it so that all CAN drivers, without exception, support the software TX timestamps. Add a call to skb_tx_timestamp() in the vcan_tx() and vxcan_xmit() functions so that the modules now support TX software timestamps. [1] commit 741b91f1b0ea ("can: dev: can_put_echo_skb(): add software tx timestamps") Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=741b91f1b0ea34f00f6a7d4539b767c409291fcf Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/all/20220727101641.198847-5-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde

can: vxcan: vxcan_xmit(): use kfree_skb() instead of kfree() to free skb

2022-03-13T08:45:35+00:00

This patch fixes the freeing of the "oskb", by using kfree_skb() instead of kfree(). Fixes: 1574481bb3de ("vxcan: remove sk reference in peer skb") Link: https://lore.kernel.org/all/20220311123741.382618-1-mkl@pengutronix.de Cc: Oliver Hartkopp Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Marc Kleine-Budde

vxcan: enable local echo for sent CAN frames

2022-03-10T08:23:45+00:00

The vxcan driver provides a pair of virtual CAN interfaces to exchange CAN traffic between different namespaces - analogue to veth. In opposite to the vcan driver the local sent CAN traffic on this interface is not echo'ed back but only sent to the remote peer. This is unusual and can be easily fixed by removing IFF_ECHO from the netdevice flags that are set for vxcan interfaces by default at startup. Without IFF_ECHO set on driver level, the local sent CAN frames are echo'ed in af_can.c in can_send(). This patch makes vxcan interfaces adopt the same local echo behavior and procedures as known from the vcan interfaces. Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)") Link: https://lore.kernel.org/all/20220309120416.83514-5-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde

vxcan: remove sk reference in peer skb

2022-03-10T08:23:45+00:00

With can_create_echo_skb() the skb which is forwarded to the peer CAN interface shares the sk pointer from the originating socket. This makes the CAN frame show up in the peer namespace as a TX packet. With the use of skb_clone() analogue to the handling in gw.c the peer skb gets a new start in the peer namespace and correctly appears as a RX packet. Link: https://lore.kernel.org/all/20220309120416.83514-4-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde

can: Use netif_rx().

2022-03-06T11:05:31+00:00

Since commit baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any context.") the function netif_rx() can be used in preemptible/thread context as well as in interrupt context. Use netif_rx(). Cc: Marc Kleine-Budde Cc: Oliver Hartkopp Cc: Wolfgang Grandegger Cc: linux-can@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior Acked-by: Oliver Hartkopp Acked-by: Marc Kleine-Budde Signed-off-by: David S. Miller

can: do not increase tx_bytes statistics for RTR frames

2022-01-05T11:09:05+00:00

The actual payload length of the CAN Remote Transmission Request (RTR) frames is always 0, i.e. no payload is transmitted on the wire. However, those RTR frames still use the DLC to indicate the length of the requested frame. As such, net_device_stats::tx_bytes should not be increased when sending RTR frames. The function can_get_echo_skb() already returns the correct length, even for RTR frames (c.f. [1]). However, for historical reasons, the drivers do not use can_get_echo_skb()'s return value and instead, most of them store a temporary length (or dlc) in some local structure or array. Using the return value of can_get_echo_skb() solves the issue. After doing this, such length/dlc fields become unused and so this patch does the adequate cleaning when needed. This patch fixes all the CAN drivers. Finally, can_get_echo_skb() is decorated with the __must_check attribute in order to force future drivers to correctly use its return value (else the compiler would emit a warning). [1] commit ed3320cec279 ("can: dev: __can_get_echo_skb(): fix real payload length return value for RTR frames") Link: https://lore.kernel.org/all/20211207121531.42941-6-mailhol.vincent@wanadoo.fr Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Jernej Skrabec Cc: Yasushi SHOJI Cc: Oliver Hartkopp Cc: Stephane Grosjean Cc: Andreas Larsson Tested-by: Jimmy Assarsson # kvaser Signed-off-by: Vincent Mailhol Acked-by: Stefan Mätje # esd_usb2 Tested-by: Stefan Mätje # esd_usb2 [mkl: add conversion for grcan] Signed-off-by: Marc Kleine-Budde

net: introduce CAN specific pointer in the struct net_device

2021-02-24T22:32:15+00:00

Since 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv") the CAN framework uses per device specific data in the AF_CAN protocol. For this purpose the struct net_device->ml_priv is used. Later the ml_priv usage in CAN was extended for other users, one of them being CAN_J1939. Later in the kernel ml_priv was converted to an union, used by other drivers. E.g. the tun driver started storing it's stats pointer. Since tun devices can claim to be a CAN device, CAN specific protocols will wrongly interpret this pointer, which will cause system crashes. Mostly this issue is visible in the CAN_J1939 stack. To fix this issue, we request a dedicated CAN pointer within the net_device struct. Reported-by: syzbot+5138c4dd15a0401bec7b@syzkaller.appspotmail.com Fixes: 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv") Fixes: ffd956eef69b ("can: introduce CAN midlayer private and allocate it automatically") Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20210223070127.4538-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski