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