Hi Hangbin, all,
thanks for your feedback!
In fact checking for dev->ml_priv != NULL seems to be too hard and would likely create some breaking setups.
I have sent a patch on the Linux-CAN ML that makes the CAN subsystem robust against alien ARPHRD_CAN interfaces that might be created by TUN/TAP via TUNSETLINK ioctl:
https://lore.kernel.org/linux-can/20260819160822.8256-1-socketcan@hartkopp.net/ (local)
The other question remains how to make bonding/team keep the fingers away from incompatible net devices.
The current black listing approach from Jiale Yao (using a unified helper as suggested by Jiri Pirko) seems to be the best way to go now:
https://lore.kernel.org/netdev/20260728151240.89434-1-yaojiale02@163.com/ (local)
+ if (port_dev->type == ARPHRD_CAN ||
+ port_dev->type == ARPHRD_IEEE802154 ||
+ port_dev->type == ARPHRD_IEEE802154_MONITOR) {
+ NL_SET_ERR_MSG(extack,
+ "CAN and IEEE 802.15.4 devices can't be added as a team port");
+ netdev_err(dev, "Device %s is CAN or IEEE 802.15.4. These device types can't be added as a team port\n",
+ portname);
+ return -EINVAL;
+ }
+ }
+
There might be other dev->types (e.g. ARPHRD_ARCNET) or a future white list approach this unified helper could support. For either team and bonding!
@Jiale Yao: What would be a good name for such helper in include/linux/if_arp.h ?
dev_is_not_ether_compatible(const struct net_device *dev)
dev_is_ether_compatible(const struct net_device *dev)
dev_has_special_l2_proto(const struct net_device *dev)
dev_has_l2_proto(const struct net_device *dev)
dev_is_pure_packet_bus(const struct net_device *dev)
or something like this?
Best regards,
Oliver
ps. independently of these two patches I would suggest to implement proper user assignments for ml_priv users using netdev_get_ml_priv() and netdev_set_ml_priv() as we have for CAN, e.g.
enum netdev_ml_priv_type {
ML_PRIV_NONE,
ML_PRIV_CAN,
ML_PRIV_QETH,
ML_PRIV_CXGB2,
ML_PRIV_I82596,
}
On 19.08.26 11:12, Hangbin Liu wrote:Hi Oliver,
On Tue, Aug 18, 2026 at 03:25:36PM +0200, Oliver Hartkopp wrote:
quoted
Hi Hangbin,
quoted
Hi Oliver,
Sashiko gives some feed back[1], would you please check it?
[1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260815153938.187073-1-socketcan%40hartkopp.net
Unfortunately the AI bot review did not create a proper answer, so that I
would be able to answer in-line.
Thanks for your reply.
quoted
Sashiko says:
"Is this test too broad for plain Ethernet slaves?
netdev_has_ml_priv() only looks at dev->ml_priv, not at dev->ml_priv_type,
so it matches any driver that stashes a private pointer there, including
ARPHRD_ETHER NICs that were never involved in the CAN crash."
and later also points out potential problems that could arise with tun.
Today only the CAN subsystem properly sets dev->ml_priv_type. Other users
simply grab dev->ml_priv for their needs (inkognito).
Yes
quoted
To me the question is whether bonding/teaming and now also tunneling code
takes care about the mid-layer private pointer dev->ml_priv?!?
AFAIK, no.
quoted
The fact that the issues have been found by syzbot for CAN devices might be
through to the fact that the virtual CAN interface (vcan) can be created by
netlink commands and can be easily used in test setups.
So what would happen, if the same tests with bonding/teaming/tunneling would
be done with real hardware drivers as the mentioned "direct ml_priv writers
still in tree at this revision:
drivers/s390/net/qeth_core_main.c:qeth_alloc_netdev()
dev->ml_priv = card;
drivers/net/ethernet/chelsio/cxgb/cxgb2.c:init_one()
netdev->ml_priv = adapter;
drivers/net/wan/hdlc_fr.c:fr_add_pvc()
dev->ml_priv = pvc;
plus drivers/net/ethernet/i825xx/82596.c, drivers/s390/net/ctcm_main.c,
the libertas main.c/mesh.c paths and
drivers/net/wireless/microchip/wilc1000/netdev.c."
??
I'm not worry about cxgb2 or 82596, which are too old. But s390 qeth is
still actively maintained (Cc the maintainers). Can we block them directly?
quoted
If bonding/teaming/tunneling might accidentally overwrite dev->ml_priv we
have to block all those devices. No matter if it is CAN or whatever ethernet
device.
How would bonding modify dev->ml_priv?
quoted
And this it what this patch aims for.
So either the users were lucky so far or they never used
bonding/teaming/tunneling on these devices? I don't know.
But it definitely looks like we should make a safe move to block all ml_priv
using devices.
Most of the referenced drivers are 20+ years old! Only
drivers/net/wireless/microchip/wilc1000/netdev.c is about 11 years old and
moved from staging into mainline in 2020. The use of ml_priv is a left-over
from the former out out tree development. The wilc1000 drivers does not use
the existing infrastructure in the correct way. In all cases this wifi
driver and all the ancient ethernet drivers should (and can) be implemented
without using the ml_priv pointer today.
When there are (unlikely) real users of those (ancient) drivers together
with bonding/teaming/tunneling those drivers should be changed in a way that
they do not need dev->ml_priv anymore.
No need to fix the ancient driver at present.
Thanks
Hangbin