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

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 14.08.26 16:45, Oliver Hartkopp wrote:
> +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)?

I've sent my idea of a combined patch fixing either the bonding and the 
teaming sides by checking the use of ml_priv here:

https://lore.kernel.org/netdev/20260815153938.187073-1-socketcan@hartkopp.net/

Many thanks and 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
>>>>
>