Skip to contentSkip to conversation

macvlan: remove duplicate check

PATCH In review Matteo Croce 2 participants 3 messages Dec 4, 2018 – Dec 6, 2018

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 macvlan: remove duplicate check

Following commit 59f997b088d2 ("macvlan: return correct error value"), there is a duplicate check for mac addresses both in macvlan_sync_address() and macvlan_set_mac_address().
As the former calls the latter, remove the one in macvlan_set_mac_address() and move the one in macvlan_sync_address() before any other check.

---
 drivers/net/macvlan.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/net/macvlan.c +3 -6
index 0da3d36b283b..f3361aabdb78 100644
@@ -700,14 +700,14 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
 	struct macvlan_port *port = vlan->port;
 	int err;
 
+	if (macvlan_addr_busy(vlan->port, addr))
+		return -EADDRINUSE;
+
 	if (!(dev->flags & IFF_UP)) {
 		/* Just copy in the new address */
 		ether_addr_copy(dev->dev_addr, addr);
 	} else {
 		/* Rehash and update the device filters */
-		if (macvlan_addr_busy(vlan->port, addr))
-			return -EADDRINUSE;
-
 		if (!macvlan_passthru(port)) {
 			err = dev_uc_add(lowerdev, addr);
 			if (err)
@@ -747,9 +747,6 @@ static int macvlan_set_mac_address(struct net_device *dev, void *p)
 		return dev_set_mac_address(vlan->lowerdev, addr);
 	}
 
-	if (macvlan_addr_busy(vlan->port, addr->sa_data))
-		return -EADDRINUSE;
-
 	return macvlan_sync_address(dev, addr->sa_data);
 }
 
Signature · 1 line
2.19.2
maintainer
#1 lore raw

From: Matteo Croce <[email protected]>
Date: Tue, 4 Dec 2018 18:05:42 +0100

Quoted 7 lines

Following commit 59f997b088d2 ("macvlan: return correct error value"), there is a duplicate check for mac addresses both in macvlan_sync_address() and macvlan_set_mac_address().
As the former calls the latter, remove the one in macvlan_set_mac_address() and move the one in macvlan_sync_address() before any other check.

Hmmm, doesn't this change behavior?

For the handling of the NETDEV_CHANGEADDR event in macvlan_device_event() we would make it to macvlan_sync_address(), and if IFF_UP is false, we would elide the macvlan_addr_busy() check and just copy the MAC addres over and return.

Now, we would always perform the macvlan_addr_busy() check.

Please, if this is OK, explain and document this behavioral chance in the commit message.

Thank you.

#2 lore raw
Quoted 19 lines · David Miller

From: Matteo Croce <[email protected]>
Date: Tue, 4 Dec 2018 18:05:42 +0100

Quoted 7 lines

Following commit 59f997b088d2 ("macvlan: return correct error value"), there is a duplicate check for mac addresses both in macvlan_sync_address() and macvlan_set_mac_address().
As the former calls the latter, remove the one in macvlan_set_mac_address() and move the one in macvlan_sync_address() before any other check.

Hmmm, doesn't this change behavior?

For the handling of the NETDEV_CHANGEADDR event in macvlan_device_event() we would make it to macvlan_sync_address(), and if IFF_UP is false, we would elide the macvlan_addr_busy() check and just copy the MAC addres over and return.

Quoted 6 lines

Now, we would always perform the macvlan_addr_busy() check.

Please, if this is OK, explain and document this behavioral chance in the commit message.

Thank you.

Hi David,

I looked at macvlan_device_event() again. Correct me if I'm wrong:
That function is meant to handle changes to the macvlan lower device. In my case, it receives an NETDEV_CHANGEADDR after the lower device mac addres is changed.
Actually events are handled only if the macvlan mode is passthru, while in all other modes NOTIFY_DONE is just returned, so macvlan_sync_address() is called only for passthru mode. The passthru mode mandates that the macvlan and phy address are the same, hence macvlan_addr_busy() skips the address comparison if the mode is passthru, and at the end, nothing happens.

Speaking of mac address change, I have a question about the generic code. If I look at the NOTIFY_BAD definition in include/linux/notifier.h, the comment states "Bad/Veto action", which suggests me that a notifier returning NOTIFY_BAD should prevent a change.
This doesn't happen because in dev_set_mac_address(), the event is sent to notifiers after the change has already made, and the result of call_netdevice_notifiers() is ignored anyway.

So in theory a notifier can deny another device address change, but in practice this doesn't happen. Does it sound right? Just asking.

Regards,

Signature · 2 lines
Matteo Croce
per aspera ad upstream