[net] 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.

Signed-off-by: Matteo Croce <mcroce@redhat.com>
---
 drivers/net/macvlan.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

From: Matteo Croce <mcroce@redhat.com>
Date: Tue,  4 Dec 2018 18:05:42 +0100

> 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.
> 
> Signed-off-by: Matteo Croce <mcroce@redhat.com>

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.

On Wed, Dec 5, 2018 at 8:40 PM David Miller <davem@davemloft.net> wrote:
>
> From: Matteo Croce <mcroce@redhat.com>
> Date: Tue,  4 Dec 2018 18:05:42 +0100
>
> > 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.
> >
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
>
> 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.

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,