Re: [PATCH net] net: do not bond/team netdevices which use ml_priv

[Hangbin Liu <hangbin.liu@linux.dev>]

On Fri, Aug 21, 2026 at 01:17:10PM +0200, Oliver Hartkopp wrote:
> On 21.08.26 03:46, Hangbin Liu wrote:
> 
> > > This caused a problem on CAN devices that were not created by the CAN driver
> > > infrastructure (creating proper ml_priv content). When TUN/TAP set the
> > > dev->type of an ethernet device to ARPHRD_CAN the CAN ml_priv is NULL (not
> > > initialized).
> > 
> > I don't know why a user change the tun/tap dev->type to CAN. Can they work
> > together? If it's a miss config, I think we can just leave it since we already
> > block CAN slave.
> 
> Correct. We currently block ARPHRD_CAN in bond_main.c
> 
> > > Not sure if collecting a bunch of ARPHRD values is the right approach or
> > > whether team/bonding should check required features and settings (like IFF
> > > flags, e.g. IFF_ARP or specific address length)?
> > 
> > Bond supports none arp devices. It also supports infiniband devices. So we
> > can't check it with IFF_ARP or address length.
> > 
> >  From my perspective, we can keep the existing check as it only causes issues
> > with CAN devices. We can work out a better solution if more incompatible
> > devices are found under bond/team.
> 
> I've checked some whitelisting ideas for bond and team which did not really
> work and turned out to be risky.
> 
> In the end the V2 patch from Jiale Yao testing for ARPHRD_CAN and
> ARPHRD_IEEE802154 / ARPHRD_IEEE802154_MONITOR (suggested by Gemini/Jakub)
> seems to be the best idea!
> 
> https://lore.kernel.org/netdev/20260728151240.89434-1-yaojiale02@163.com/
> 
> ARPHRD_IEEE802154 / ARPHRD_IEEE802154_MONITOR do similar things like the CAN
> dev->ml_priv approach but with dev->ieee802154_ptr :-/

+1

Hangbin