[PATCH] net: vlan: inherit addr_assign_type along with dev_addr

[PATCH] net: vlan: inherit addr_assign_type along with dev_addr

[Bjørn Mork]

A vlan device inheriting a random or set address should reflect
this in its addr_assign_type.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 net/8021q/vlan_dev.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 1cd3d2a..995684d 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -581,8 +581,10 @@ static int vlan_dev_init(struct net_device *dev)
 	/* ipv6 shared card related stuff */
 	dev->dev_id = real_dev->dev_id;
 
-	if (is_zero_ether_addr(dev->dev_addr))
+	if (is_zero_ether_addr(dev->dev_addr)) {
 		memcpy(dev->dev_addr, real_dev->dev_addr, dev->addr_len);
+		dev->addr_assign_type = real_dev->addr_assign_type;
+	}
 	if (is_zero_ether_addr(dev->broadcast))
 		memcpy(dev->broadcast, real_dev->broadcast, dev->addr_len);
 
-- 
1.7.10.4

Re: [PATCH] net: vlan: inherit addr_assign_type along with dev_addr

[David Miller]

From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 22 Aug 2013 14:23:21 +0200

> A vlan device inheriting a random or set address should reflect
> this in its addr_assign_type.
> 
> Signed-off-by: Bjørn Mork <bjorn@mork.no>

I think this might deserve a helper function, I'd not be surprised
if we do MAC address propagation like this in other situations and
they have the same bug.

Re: [PATCH] net: vlan: inherit addr_assign_type along with dev_addr

[Bjørn Mork]

David Miller <davem@davemloft.net> writes:

> From: Bjørn Mork <bjorn@mork.no>
> Date: Thu, 22 Aug 2013 14:23:21 +0200
>
>> A vlan device inheriting a random or set address should reflect
>> this in its addr_assign_type.
>> 
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>
> I think this might deserve a helper function, I'd not be surprised
> if we do MAC address propagation like this in other situations and
> they have the same bug.

Yes.  Grepping a bit shows that there area few more candidates. Although
some of these could probably set addr_assign_type to NET_ADDR_STOLEN
(like the bonding driver does) instead.  Maybe that should depend on the
addr_assign_type of the source device?

Never mind. I don't know what this should look like. I'll prepare a
patch set with a helper, and propose changes to all the candidate
drivers I can find, leaving it up to the maintainers to object if they
don't like it.


Bjørn