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

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

[Oliver Hartkopp]

Commit 8ba68464e478 ("bonding: refuse to enslave CAN devices") already
addressed a syzbot kernel paging request crash report for bonding.
The same problem is also valid for the team device driver as both work on
netdevices without taking care of the private mid-layer data structures.

To reject ARPHRD_CAN, ARPHRD_IEEE802154, and ARPHRD_IEEE802154_MONITOR
netdevices does not solve the root cause of the problem as ml_priv is also
used by some ancient ethernet drivers like S/390 or 82596 based drivers.
Today those ethernet drivers likely would not use ml_priv at all.

Make sure that only capable netdevices are offered to teaming and bonding
by checking that ml_priv is unused.

Fixes: 8ba68464e478 ("bonding: refuse to enslave CAN devices")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
 drivers/net/bonding/bond_main.c | 4 ++--
 drivers/net/team/team_core.c    | 7 +++++++
 include/linux/netdevice.h       | 5 +++++
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 522eab060f9e..bbb344b67458 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1892,13 +1892,13 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
 	const struct net_device_ops *slave_ops = slave_dev->netdev_ops;
 	struct slave *new_slave = NULL, *prev_slave;
 	struct sockaddr_storage ss;
 	int res = 0, i;
 
-	if (slave_dev->type == ARPHRD_CAN) {
+	if (netdev_has_ml_priv(slave_dev)) {
 		BOND_NL_ERR(bond_dev, extack,
-			    "CAN devices cannot be enslaved");
+			    "devices using ml_priv cannot be enslaved");
 		return -EPERM;
 	}
 
 	if (slave_dev->flags & IFF_MASTER &&
 	    !netif_is_bond_master(slave_dev)) {
diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
index feaa75fbf8fc..8bf4c1c5d657 100644
--- a/drivers/net/team/team_core.c
+++ b/drivers/net/team/team_core.c
@@ -1215,10 +1215,17 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
 	struct net_device *dev = netdev_from_priv(team);
 	struct team_port *port;
 	char *portname = port_dev->name;
 	int err;
 
+	if (netdev_has_ml_priv(port_dev)) {
+		NL_SET_ERR_MSG(extack, "devices using ml_priv can't be added as a team port");
+		netdev_err(dev, "Device %s using ml_priv can't be added as a team port\n",
+			   portname);
+		return -EINVAL;
+	}
+
 	if (port_dev->flags & IFF_LOOPBACK) {
 		NL_SET_ERR_MSG(extack, "Loopback device can't be added as a team port");
 		netdev_err(dev, "Device %s is loopback device. Loopback devices can't be added as a team port\n",
 			   portname);
 		return -EINVAL;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8840b126979f..74536f642b41 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2784,10 +2784,15 @@ static inline void netdev_set_ml_priv(struct net_device *dev,
 
 	dev->ml_priv = ml_priv;
 	dev->ml_priv_type = type;
 }
 
+static inline bool netdev_has_ml_priv(struct net_device *dev)
+{
+	return (dev->ml_priv != NULL);
+}
+
 /*
  * Net namespace inlines
  */
 static inline
 struct net *dev_net(const struct net_device *dev)
-- 
2.53.0

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

[Stephen Hemminger]

On Sat, 15 Aug 2026 17:39:38 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:

> +static inline bool netdev_has_ml_priv(struct net_device *dev)
> +{
> +	return (dev->ml_priv != NULL);
> +}
> +

Minor suggestion: use const and drop unneeded parens

static inline bool netdev_has_ml_priv(const struct net_device *dev)
{
	return dev->ml_priv != NULL;
}

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

[Oliver Hartkopp]

On 15.08.26 18:00, Stephen Hemminger wrote:
> On Sat, 15 Aug 2026 17:39:38 +0200
> Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> 
>> +static inline bool netdev_has_ml_priv(struct net_device *dev)
>> +{
>> +	return (dev->ml_priv != NULL);
>> +}
>> +
> 
> Minor suggestion: use const and drop unneeded parens
> 
> static inline bool netdev_has_ml_priv(const struct net_device *dev)
> {
> 	return dev->ml_priv != NULL;
> }
> 
> 

Good point!

Will wait for some more feedback before sending a v2.

Many thanks,
Oliver

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

[Hangbin Liu]

On Sat, Aug 15, 2026 at 07:23:35PM +0200, Oliver Hartkopp wrote:
> 
> 
> On 15.08.26 18:00, Stephen Hemminger wrote:
> > On Sat, 15 Aug 2026 17:39:38 +0200
> > Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> > 
> > > +static inline bool netdev_has_ml_priv(struct net_device *dev)
> > > +{
> > > +	return (dev->ml_priv != NULL);
> > > +}
> > > +
> > 
> > Minor suggestion: use const and drop unneeded parens
> > 
> > static inline bool netdev_has_ml_priv(const struct net_device *dev)
> > {
> > 	return dev->ml_priv != NULL;
> > }
> > 
> > 
> 
> Good point!
> 
> Will wait for some more feedback before sending a v2.

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

Thanks
Hangbin

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

[Oliver Hartkopp]

Hi Hangbin,

On 18.08.26 12:12, Hangbin Liu wrote:
> On Sat, Aug 15, 2026 at 07:23:35PM +0200, Oliver Hartkopp wrote:
>>
>>
>> On 15.08.26 18:00, Stephen Hemminger wrote:
>>> On Sat, 15 Aug 2026 17:39:38 +0200
>>> Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>>
>>>> +static inline bool netdev_has_ml_priv(struct net_device *dev)
>>>> +{
>>>> +	return (dev->ml_priv != NULL);
>>>> +}
>>>> +
>>>
>>> Minor suggestion: use const and drop unneeded parens
>>>
>>> static inline bool netdev_has_ml_priv(const struct net_device *dev)
>>> {
>>> 	return dev->ml_priv != NULL;
>>> }
>>>
>>>
>>
>> Good point!
>>
>> Will wait for some more feedback before sending a v2.
> 
> 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.

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).

To me the question is whether bonding/teaming and now also tunneling 
code takes care about the mid-layer private pointer dev->ml_priv?!?

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."

??

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.

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.

For that reason

static inline bool netdev_has_ml_priv(struct net_device *dev)
{
	return dev->ml_priv != NULL;
}

seems to be the safe solution that would point out potential problems 
with those drivers immediately.

Best regards,
Oliver

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

[Hangbin Liu]

Hi Oliver,
On Tue, Aug 18, 2026 at 03:25:36PM +0200, Oliver Hartkopp wrote:
> Hi Hangbin,
> > 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

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

[Oliver Hartkopp]

Hi Hangbin, all,

thanks for your feedback!

In fact checking for dev->ml_priv != NULL seems to be too hard and would 
likely create some breaking setups.

I have sent a patch on the Linux-CAN ML that makes the CAN subsystem 
robust against alien ARPHRD_CAN interfaces that might be created by 
TUN/TAP via TUNSETLINK ioctl:

https://lore.kernel.org/linux-can/20260819160822.8256-1-socketcan@hartkopp.net/

The other question remains how to make bonding/team keep the fingers 
away from incompatible net devices.

The current black listing approach from Jiale Yao (using a unified 
helper as suggested by Jiri Pirko) seems to be the best way to go now:

https://lore.kernel.org/netdev/20260728151240.89434-1-yaojiale02@163.com/

+		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;
+		}
+	}
+

There might be other dev->types (e.g. ARPHRD_ARCNET) or a future white 
list approach this unified helper could support. For either team and 
bonding!

@Jiale Yao: What would be a good name for such helper in 
include/linux/if_arp.h ?

dev_is_not_ether_compatible(const struct net_device *dev)
dev_is_ether_compatible(const struct net_device *dev)
dev_has_special_l2_proto(const struct net_device *dev)
dev_has_l2_proto(const struct net_device *dev)
dev_is_pure_packet_bus(const struct net_device *dev)

or something like this?

Best regards,
Oliver

ps. independently of these two patches I would suggest to implement 
proper user assignments for ml_priv users using netdev_get_ml_priv() and 
netdev_set_ml_priv() as we have for CAN, e.g.

enum netdev_ml_priv_type {
	ML_PRIV_NONE,
	ML_PRIV_CAN,
	ML_PRIV_QETH,
	ML_PRIV_CXGB2,
	ML_PRIV_I82596,
}

On 19.08.26 11:12, Hangbin Liu wrote:
> Hi Oliver,
> On Tue, Aug 18, 2026 at 03:25:36PM +0200, Oliver Hartkopp wrote:
>> Hi Hangbin,
>>> 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
> 

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

[Hangbin Liu]

On Wed, Aug 19, 2026 at 08:15:42PM +0200, Oliver Hartkopp wrote:
> Hi Hangbin, all,
> 
> thanks for your feedback!
> 
> In fact checking for dev->ml_priv != NULL seems to be too hard and would
> likely create some breaking setups.
> 
> I have sent a patch on the Linux-CAN ML that makes the CAN subsystem robust
> against alien ARPHRD_CAN interfaces that might be created by TUN/TAP via
> TUNSETLINK ioctl:
> 
> https://lore.kernel.org/linux-can/20260819160822.8256-1-socketcan@hartkopp.net/
> 
> The other question remains how to make bonding/team keep the fingers away
> from incompatible net devices.
> 
> The current black listing approach from Jiale Yao (using a unified helper as
> suggested by Jiri Pirko) seems to be the best way to go now:
> 
> https://lore.kernel.org/netdev/20260728151240.89434-1-yaojiale02@163.com/
> 
> +		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;
> +		}
> +	}
> +

This looks good to me to avoid making the checking to wide.

> 
> There might be other dev->types (e.g. ARPHRD_ARCNET) or a future white list
> approach this unified helper could support. For either team and bonding!
> 
> @Jiale Yao: What would be a good name for such helper in
> include/linux/if_arp.h ?
> 
> dev_is_not_ether_compatible(const struct net_device *dev)
> dev_is_ether_compatible(const struct net_device *dev)
> dev_has_special_l2_proto(const struct net_device *dev)
> dev_has_l2_proto(const struct net_device *dev)
> dev_is_pure_packet_bus(const struct net_device *dev)
> 
> or something like this?

I'm not good at naming. Leave it to you.

Thanks for your works!

Hangbin

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

[Alexandra Winter]

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.

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

[Oliver Hartkopp]

Hi Alexandra,

On 20.08.26 10:29, Alexandra Winter wrote:
> 
> 
> 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.

Agreed.

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

Ack.

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

I did some more investigation on all this.

There are 5 drivers that are using ml_priv:

- qeth
- ctcm
- cxgb2
- i596
- wilc1000

where qeth and i596 are using it to store a single pointer which can 
also be done by adding this pointer to their netdev_priv structure.

wilc1000 assigns ml_priv and never reads from it (development leftover).

Only cxgb2 and ctcm use it in a more complex way that would make it 
tricky to move its functionality into netdev_priv without having real 
hardware on the desk.

Either team and bonding do not fiddle with ml_priv on their own. But 
they make assumptions that best fit to ethernet devices where they don't 
care about nor copy any ml_priv pointers.

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).

Long story short:

The ml_priv assignment in wilc100 can be removed.
For ethernet devices like the qeth there's no problem AFAICS.
But I would think about making use of netdev_priv() there:

diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h
index 41fe8a0..b21bccc 100644
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -798,8 +798,20 @@ struct qeth_priv {
         unsigned int tx_wanted_queues;
         u32 brport_hw_features;
         u32 brport_features;
+       struct qeth_card *card;
  };

+static inline struct qeth_card *qeth_dev_get_card(struct net_device *dev)
+{
+       return ((struct qeth_priv *)netdev_priv(dev))->card;
+}
+
+static inline void qeth_dev_set_card(struct net_device *dev,
+                                     struct qeth_card *card)
+{
+       ((struct qeth_priv *)netdev_priv(dev))->card = card;
+}
+

diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index 7376a45..b00fa77 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -4562,7 +4562,7 @@ void qeth_tx_timeout(struct net_device *dev, 
unsigned int txqueue)
  {
         struct qeth_card *card;

-       card = dev->ml_priv;
+       card = qeth_dev_get_card(dev);
         QETH_CARD_TEXT(card, 4, "txtimeo");
         qeth_schedule_recovery(card);
  }

(..)

A similar easy adoption could be done for i596 too.

ctcm cxgb2 should stay on ml_priv usage but they should implement the 
tagging of ml_priv, e.g.

diff --git a/drivers/s390/net/ctcm_fsms.c b/drivers/s390/net/ctcm_fsms.c
index bf917f4..a1465f3 100644
--- a/drivers/s390/net/ctcm_fsms.c
+++ b/drivers/s390/net/ctcm_fsms.c
@@ -246,7 +246,7 @@ static void chx_txdone(fsm_instance *fi, int event, 
void *arg)
  {
         struct channel *ch = arg;
         struct net_device *dev = ch->netdev;
-       struct ctcm_priv *priv = dev->ml_priv;
+       struct ctcm_priv *priv = netdev_get_ml_priv(dev, ML_PRIV_CTCM);
         struct sk_buff *skb;
         int first = 1;
         int i;

(..)

@@ -1097,7 +1097,7 @@ static struct net_device 
*ctcm_init_netdevice(struct ctcm_priv *priv)
                         CTCM_FUNTAIL);
                 return NULL;
         }
-       dev->ml_priv = priv;
+       netdev_set_ml_priv(dev, priv, ML_PRIV_CTCM);
         priv->fsm = init_fsm("ctcmdev", dev_state_names, dev_event_names,


The final question (which is not really a ml_priv issue) is how to tell 
team/bonding which netdevices are not capable to be used by them. To 
cover e.g. your ctcm driver using ARPHRD_SLIP.

The current check (bond_dev->type != slave_dev->type) would allow to 
join two type-identical interfaces, which was at least not a good idea 
for CAN. For that reason we already check (slave_dev->type == 
ARPHRD_CAN) there. Other dev->types might follow.

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

Best regards,
Oliver