Re: [PATCH v2] team: reject CAN and IEEE 802.15.4 devices in team_port_add

[Oliver Hartkopp <socketcan@hartkopp.net>]

+CC: linux-can ML

On 29.07.26 14:11, jiale yao wrote:
> How about adding a helper in include/linux/if_arp.h, similar to dev_is_mac_header_xmit()? Perhaps
> something like dev_is_can_or_ieee802154()?
> 

Good idea.

But I would rather suggest some

static inline bool netdev_has_ml_priv(struct net_device *dev)

in

include/linux/netdevice.h

next to

netdev_set_ml_priv() / netdev_get_ml_priv()

Currently only the CAN subsystem properly handles the dev->ml_priv_type 
to make sure the correct "user" of the ml_priv pointer:

/* Specifies the type of the struct net_device::ml_priv pointer */
enum netdev_ml_priv_type {
	ML_PRIV_NONE,
	ML_PRIV_CAN,
}

There are some other ethernet adapters of dev->ml_priv beyond 
ARPHRD_IEEE802154, and ARPHRD_IEEE802154_MONITOR. Not sure if those 
adapters need to be fixed.

But to be sure we don't run into problems with bonding or teaming we 
should probably simply check for (dev->ml_priv != NULL) to reject them.
No matter which netdev_ml_priv_type is set.

static inline bool netdev_has_ml_priv(struct net_device *dev) {

	return (dev->ml_priv != NULL);
}

Would you like to provide a patch introducing this helper and directly 
use it for bonding/team (with some updated comments, as the problem is 
not related to CAN and IEEE 802.15.4 devices but to the use of ml_priv)?

Best regards,
Oliver


> 
> At 2026-07-29 17:15:06, "Jiri Pirko" <jiri@resnulli.us> wrote:
>> Tue, Jul 28, 2026 at 05:12:40PM +0200, yaojiale02@163.com wrote:
>>> Enslaving a CAN or IEEE 802.15.4 device (e.g. vxcan, wpan0) to a
>>> team master triggers a NULL pointer dereference because these
>>> device types use different Layer 2 architectures from Ethernet and
>>> the team driver never initializes their private mid-layer data
>>> structures.
>>>
>>> Reject ARPHRD_CAN, ARPHRD_IEEE802154, and ARPHRD_IEEE802154_MONITOR
>>> devices in team_port_add(), mirroring the existing CAN check already
>>> present in the bonding driver since commit 8ba68464e478 ("bonding:
>>> refuse to enslave CAN devices").
>>
>> Can we perhaps have a unified helper for the check?
>>
>>
>>>
>>> Link: https://lore.kernel.org/all/b58d98e0-8fe3-4e4e-b8a5-c1c7e647ccca@hartkopp.net/
>>> Fixes: 1d76efe1577b ("team: add support for non-ethernet devices")
>>> Assisted-by: Claude:deepseek-v4-pro
>>
>> Looks your ai gone a bit wild here...
>>
>>
>>> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>>> ---
>>> V1 -> V2: Extended check to also reject ARPHRD_IEEE802154 and
>>>   ARPHRD_IEEE802154_MONITOR devices per review feedback
>>> ---
>>> drivers/net/team/team_core.c | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
>>> index feaa75fbf8fc..d8c46105fc8b 100644
>>> --- a/drivers/net/team/team_core.c
>>> +++ b/drivers/net/team/team_core.c
>>> @@ -1224,6 +1224,17 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
>>> 		return -EINVAL;
>>> 	}
>>>
>>> +		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;
>>> +		}
>>> +	}
>>> +
>>> 	if (netif_is_team_port(port_dev)) {
>>> 		NL_SET_ERR_MSG(extack, "Device is already a port of a team device");
>>> 		netdev_err(dev, "Device %s is already a port "
>>> -- 
>>> 2.34.1
>>>