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

Hi Oliver,
On Tue, Aug 18, 2026 at 03:25:36PM +0200, Oliver Hartkopp wrote:

Hi Hangbin,

quoted

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