macvlan: remove duplicate check
Subsystems (2)
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
@@ -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
David Miller
maintainerFrom: 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 inmacvlan_sync_address()andmacvlan_set_mac_address().
As the former calls the latter, remove the one inmacvlan_set_mac_address()and move the one inmacvlan_sync_address()before any other check.Signed-off-by Matteo Croce <[email protected]>
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.
Quoted 19 lines · David Miller
From: Matteo Croce <[email protected]>
Date: Tue, 4 Dec 2018 18:05:42 +0100Quoted 7 lines
Following commit
59f997b088d2("macvlan: return correct error value"), there is a duplicate check for mac addresses both inmacvlan_sync_address()andmacvlan_set_mac_address().
As the former calls the latter, remove the one inmacvlan_set_mac_address()and move the one inmacvlan_sync_address()before any other check.Signed-off-by Matteo Croce <[email protected]>Hmmm, doesn't this change behavior?
For the handling of the
NETDEV_CHANGEADDRevent inmacvlan_device_event()we would make it tomacvlan_sync_address(), and ifIFF_UPis false, we would elide themacvlan_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