# Re: \[PATCH net\] net: do not bond/team netdevices which use ml\_priv

- From: Alexandra Winter \<wintera@linux.ibm.com\>
- Date: 2026-08-20 08:29:19 
- List: netdev
- Page: https://ratatoskr.run/netdev/2026/08/17437335
- Thread: https://ratatoskr.run/netdev/2026/08/17417014/t.md

```text


On 19.08.26 11:12, Hangbin Liu wrote:
>> 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?


Thank you very much for the Cc I would have missed this otherwise.
While drivers/s390/net/qeth may be decades old, it is still the most used
network driver for the s390 architecture.

!!
qeth_l2 is an ethernet driver and bonding is heavily used by our customers.
So: No, please do NOT block bonding over qeth.

I see your discussion has moved on to other options, but I wanted to point that out.



qeth_l3 is a transport layer driver (arp offloaded), so I don't think bonding or teaming
can work at all there.
ctcm is not based on ethernet, so I don't think bonding or teaming can work there neither.
Aswin and I will put it on our ToDo list to find out what happens, if somebody tries.
Maybe we to add them to the blacklist you mention in a later reply?


> 
>> 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?


Could you give more information about this?
I hope there is no issue for qeth_l2. There we use and rely on dev->ml_priv.



```