# Re: \[PATCH net\] net: do not bond/team netdevices which use ml\_priv

- From: Oliver Hartkopp \<socketcan@hartkopp.net\>
- Date: 2026-08-19 18:16:10 
- List: netdev
- Page: https://ratatoskr.run/netdev/2026/08/17435330
- Thread: https://ratatoskr.run/netdev/2026/08/17417014/t.md

```text
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/

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/

+		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:
>> Hi Hangbin,
>>> 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.
>
>>
>> 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
>
>>
>> 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.
>
>>
>> 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?
>
>>
>> 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?
>
>>
>> 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
>

```