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

[Oliver Hartkopp]

+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@xxxxxxxxxxx> wrote:
> > Tue, Jul 28, 2026 at 05:12:40PM +0200, yaojiale02@xxxxxxx 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@xxxxxxxxxxxx/
> > > 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@xxxxxxx>
> > > ---
> > > 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