[PATCH net-next v2 RESEND 0/4] macvlan: fix some problem if mac address changes

[PATCH net-next v2 RESEND 0/4] macvlan: fix some problem if mac address changes

[Ding Tianhong]

The macvlan may return failed when handle the NETDEV_CHANGEMTU message, and
the current code could not process the error value, so modify the
dev_set_mac_address to process the return value for notification chain,
revert the old mac address if set new mac address failed.

The macvlan and lowerdev should not have the same mac address for non-passthru
mode, so add restriction for that.

v1->v2: Now the current code support setting a same mac address for netdev, but
	most of time, it make no sense, but drivers need the user set flag regardless
	the address is same or not, so don't do anything only If the address has
	already been set by user and it is the same as before.

	If the lowerdev support L2 fwd offload, the macvlan address will be set to
	the hw rar only, and it the address changes, the fwd for macvlan need be rebuild,
	this patchset support this.

Ding Tianhong (4):
  macvlan: support mac address changes when fwd_priv is enable
  net: dev: revert the mac address when notifier failed
  macvlan: don't set the same mac address for non-passthru mode
  net: dev: don't set the same mac address for netdev

 drivers/net/macvlan.c | 27 ++++++++++++++++++++++++++-
 net/core/dev.c        | 30 ++++++++++++++++++++++++++----
 2 files changed, 52 insertions(+), 5 deletions(-)

-- 
1.8.0

[PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd_priv is enable

[Ding Tianhong]

If lowerdev supports L2 forwarding offload, the macvlan's hw address
will be set to the rar of the lowerdev and no need to set uc list,
and when the macvlan's hw address changes, the macvlan should remove
the old fwd and rebuild a new fwd for the macvlan.

Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
 drivers/net/macvlan.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 453d55a..67485ab 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
 		if (macvlan_addr_busy(vlan->port, addr))
 			return -EBUSY;
 
+		if (vlan->fwd_priv) {
+			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
+								   vlan->fwd_priv);
+			vlan->fwd_priv = NULL;
+			ether_addr_copy(dev->perm_addr, dev->dev_addr);
+			ether_addr_copy(dev->dev_addr, addr);
+			vlan->fwd_priv =
+			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
+								       dev);
+			/* If we get a NULL pointer back, or if we get an error
+			 * then we should restore the old mac address and fwd.
+			 */
+			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
+				ether_addr_copy(dev->dev_addr, dev->perm_addr);
+				vlan->fwd_priv =
+				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
+									       dev);
+				return -EINVAL;
+			}
+			return 0;
+		}
 		if (!vlan->port->passthru) {
 			err = dev_uc_add(lowerdev, addr);
 			if (err)
-- 
1.8.0

[PATCH net-next v2 RESEND 2/4] net: dev: revert the mac address when notifier failed

[Ding Tianhong]

When set a new mac address to a netdev, the dev should propagate
to the upperdev or lowerdev and make sure the new mac address could
work well with other devs, otherwise the new mac address shouldn't
be set and revert the old mac address.

Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
 net/core/dev.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 5367bfb..b0fb3dd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5562,6 +5562,7 @@ EXPORT_SYMBOL(dev_set_group);
 int dev_set_mac_address(struct net_device *dev, struct sockaddr *sa)
 {
 	const struct net_device_ops *ops = dev->netdev_ops;
+	struct sockaddr old_sa;
 	int err;
 
 	if (!ops->ndo_set_mac_address)
@@ -5570,13 +5571,27 @@ int dev_set_mac_address(struct net_device *dev, struct sockaddr *sa)
 		return -EINVAL;
 	if (!netif_device_present(dev))
 		return -ENODEV;
+
+	old_sa.sa_family = dev->type;
+	ether_addr_copy(old_sa.sa_data, dev->dev_addr);
+
 	err = ops->ndo_set_mac_address(dev, sa);
 	if (err)
 		return err;
-	dev->addr_assign_type = NET_ADDR_SET;
-	call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
-	add_device_randomness(dev->dev_addr, dev->addr_len);
-	return 0;
+
+	err = call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
+	err = notifier_to_errno(err);
+	if (err) {
+		/* setting mac address back and notify everyone again,
+		 *  so that they have a chance to revert changes.
+		 */
+		ops->ndo_set_mac_address(dev, &old_sa);
+		call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
+	} else {
+		dev->addr_assign_type = NET_ADDR_SET;
+		add_device_randomness(dev->dev_addr, dev->addr_len);
+	}
+	return err;
 }
 EXPORT_SYMBOL(dev_set_mac_address);
 
-- 
1.8.0

[PATCH net-next v2 RESEND 3/4] macvlan: don't set the same mac address for non-passthru mode

[Ding Tianhong]

The macvlan should have the same mac address only for passthru mode,
so the underlying device couldn't set a new address if it is in use
by macvlan for non-passthru mode, otherwise it will break the work
mechanism.

Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
 drivers/net/macvlan.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 67485ab..b6a0065 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -1206,8 +1206,12 @@ static int macvlan_device_event(struct notifier_block *unused,
 		}
 		break;
 	case NETDEV_CHANGEADDR:
-		if (!port->passthru)
+		if (!port->passthru) {
+			if (macvlan_hash_lookup(port, dev->dev_addr))
+				return NOTIFY_BAD;
+
 			return NOTIFY_DONE;
+		}
 
 		vlan = list_first_entry_or_null(&port->vlans,
 						struct macvlan_dev,
-- 
1.8.0

[PATCH net-next v2 RESEND 4/4] net: dev: don't set the same mac address for netdev

[Ding Tianhong]

Most of netdev just link bond, team, vlan will set the mac address
and propagate to the upperdev or lowerdev regardless the mac address
is same or not, setting a same mac address make no sense for most of
the netdev, but some netdev need a flag to see whether the ndo_set_mac_address()
is called and decide what to do next, so don't do anything if the address
has already been set by user and it is the same as before, otherwise set
the same address to the netdev.

Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
 net/core/dev.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index b0fb3dd..201d88b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5572,6 +5572,13 @@ int dev_set_mac_address(struct net_device *dev, struct sockaddr *sa)
 	if (!netif_device_present(dev))
 		return -ENODEV;
 
+	/* If the address has already been set by user and it
+	 * is the same as before, don't do anything.
+	 */
+	if (dev->addr_assign_type == NET_ADDR_SET &&
+	    ether_addr_equal_64bits(dev->dev_addr, sa->sa_data))
+		return 0;
+
 	old_sa.sa_family = dev->type;
 	ether_addr_copy(old_sa.sa_data, dev->dev_addr);
 
-- 
1.8.0

Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd_priv is enable

[Vlad Yasevich]

[.. CC John Fastabend <john.r.fastabend@intel.com> ]

On 06/07/2014 03:45 AM, Ding Tianhong wrote:
> If lowerdev supports L2 forwarding offload, the macvlan's hw address
> will be set to the rar of the lowerdev and no need to set uc list,
> and when the macvlan's hw address changes, the macvlan should remove
> the old fwd and rebuild a new fwd for the macvlan.
> 
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 453d55a..67485ab 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>  		if (macvlan_addr_busy(vlan->port, addr))
>  			return -EBUSY;
>  
> +		if (vlan->fwd_priv) {
> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
> +								   vlan->fwd_priv);
> +			vlan->fwd_priv = NULL;
> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
> +			ether_addr_copy(dev->dev_addr, addr);
> +			vlan->fwd_priv =
> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
> +								       dev);
> +			/* If we get a NULL pointer back, or if we get an error
> +			 * then we should restore the old mac address and fwd.
> +			 */
> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
> +				vlan->fwd_priv =
> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
> +									       dev);
> +				return -EINVAL;
> +			}
> +			return 0;
> +		}

Calling del_stations add_station causes all sorts of VMDQ/ring
operations to happen...  Not sure if we can do that while we have a live
macvlan/macvtap that is capable of transmitting data.

Wouldn't it be sufficient to have a call to call to update with mac
filter with the appropriate VMDQ.

John, I defer to you here.  The above looks really heavy-weight and
I am not sure if its correct.

Thanks
-vlad

>  		if (!vlan->port->passthru) {
>  			err = dev_uc_add(lowerdev, addr);
>  			if (err)
> 

Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd_priv is enable

[Ding Tianhong]

On 2014/6/10 0:51, Vlad Yasevich wrote:
> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
> 
> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>> will be set to the rar of the lowerdev and no need to set uc list,
>> and when the macvlan's hw address changes, the macvlan should remove
>> the old fwd and rebuild a new fwd for the macvlan.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>> index 453d55a..67485ab 100644
>> --- a/drivers/net/macvlan.c
>> +++ b/drivers/net/macvlan.c
>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>  		if (macvlan_addr_busy(vlan->port, addr))
>>  			return -EBUSY;
>>  
>> +		if (vlan->fwd_priv) {
>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>> +								   vlan->fwd_priv);
>> +			vlan->fwd_priv = NULL;
>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>> +			ether_addr_copy(dev->dev_addr, addr);
>> +			vlan->fwd_priv =
>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>> +								       dev);
>> +			/* If we get a NULL pointer back, or if we get an error
>> +			 * then we should restore the old mac address and fwd.
>> +			 */
>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>> +				vlan->fwd_priv =
>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>> +									       dev);
>> +				return -EINVAL;
>> +			}
>> +			return 0;
>> +		}
> 
> Calling del_stations add_station causes all sorts of VMDQ/ring
> operations to happen...  Not sure if we can do that while we have a live
> macvlan/macvtap that is capable of transmitting data.
> 
> Wouldn't it be sufficient to have a call to call to update with mac
> filter with the appropriate VMDQ.
> 
> John, I defer to you here.  The above looks really heavy-weight and
> I am not sure if its correct.
> 
> Thanks
> -vlad

I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
work well with the maclvan, so I don't think this solution has problem.

Thanks
Ding

> 
>>  		if (!vlan->port->passthru) {
>>  			err = dev_uc_add(lowerdev, addr);
>>  			if (err)
>>
> 
> 
> .
> 

Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd_priv is enable

[Vlad Yasevich]

On 06/11/2014 09:45 PM, Ding Tianhong wrote:
> On 2014/6/10 0:51, Vlad Yasevich wrote:
>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>
>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>> will be set to the rar of the lowerdev and no need to set uc list,
>>> and when the macvlan's hw address changes, the macvlan should remove
>>> the old fwd and rebuild a new fwd for the macvlan.
>>>
>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>> ---
>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>  1 file changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>> index 453d55a..67485ab 100644
>>> --- a/drivers/net/macvlan.c
>>> +++ b/drivers/net/macvlan.c
>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>  			return -EBUSY;
>>>  
>>> +		if (vlan->fwd_priv) {
>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>> +								   vlan->fwd_priv);
>>> +			vlan->fwd_priv = NULL;
>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>> +			ether_addr_copy(dev->dev_addr, addr);
>>> +			vlan->fwd_priv =
>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>> +								       dev);
>>> +			/* If we get a NULL pointer back, or if we get an error
>>> +			 * then we should restore the old mac address and fwd.
>>> +			 */
>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>> +				vlan->fwd_priv =
>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>> +									       dev);
>>> +				return -EINVAL;
>>> +			}
>>> +			return 0;
>>> +		}
>>
>> Calling del_stations add_station causes all sorts of VMDQ/ring
>> operations to happen...  Not sure if we can do that while we have a live
>> macvlan/macvtap that is capable of transmitting data.
>>
>> Wouldn't it be sufficient to have a call to call to update with mac
>> filter with the appropriate VMDQ.
>>
>> John, I defer to you here.  The above looks really heavy-weight and
>> I am not sure if its correct.
>>
>> Thanks
>> -vlad
> 
> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
> work well with the maclvan, so I don't think this solution has problem.

Have you tried changing the address while at the same time
transmitting data through the macvlan?

-vlad

> 
> Thanks
> Ding
> 
>>
>>>  		if (!vlan->port->passthru) {
>>>  			err = dev_uc_add(lowerdev, addr);
>>>  			if (err)
>>>
>>
>>
>> .
>>
> 
> 

Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd_priv is enable

[Ding Tianhong]

On 2014/6/12 22:24, Vlad Yasevich wrote:
> On 06/11/2014 09:45 PM, Ding Tianhong wrote:
>> On 2014/6/10 0:51, Vlad Yasevich wrote:
>>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>>
>>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>>> will be set to the rar of the lowerdev and no need to set uc list,
>>>> and when the macvlan's hw address changes, the macvlan should remove
>>>> the old fwd and rebuild a new fwd for the macvlan.
>>>>
>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>> ---
>>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>>  1 file changed, 21 insertions(+)
>>>>
>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>> index 453d55a..67485ab 100644
>>>> --- a/drivers/net/macvlan.c
>>>> +++ b/drivers/net/macvlan.c
>>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>>  			return -EBUSY;
>>>>  
>>>> +		if (vlan->fwd_priv) {
>>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>>> +								   vlan->fwd_priv);
>>>> +			vlan->fwd_priv = NULL;
>>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>>> +			ether_addr_copy(dev->dev_addr, addr);
>>>> +			vlan->fwd_priv =
>>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>> +								       dev);
>>>> +			/* If we get a NULL pointer back, or if we get an error
>>>> +			 * then we should restore the old mac address and fwd.
>>>> +			 */
>>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>>> +				vlan->fwd_priv =
>>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>> +									       dev);
>>>> +				return -EINVAL;
>>>> +			}
>>>> +			return 0;
>>>> +		}
>>>
>>> Calling del_stations add_station causes all sorts of VMDQ/ring
>>> operations to happen...  Not sure if we can do that while we have a live
>>> macvlan/macvtap that is capable of transmitting data.
>>>
>>> Wouldn't it be sufficient to have a call to call to update with mac
>>> filter with the appropriate VMDQ.
>>>
>>> John, I defer to you here.  The above looks really heavy-weight and
>>> I am not sure if its correct.
>>>
>>> Thanks
>>> -vlad
>>
>> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
>> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
>> work well with the maclvan, so I don't think this solution has problem.
> 
> Have you tried changing the address while at the same time
> transmitting data through the macvlan?
> 
> -vlad
> 

Yes, I tried, the lowerdev will be closed when calling ixgbe_fwd_del, then the transmitting was broken and about 1 second later,
the transmitting restored and start to work again.

64 bytes from 192.168.10.8: icmp_seq=14 ttl=64 time=0.109 ms
64 bytes from 192.168.10.8: icmp_seq=15 ttl=64 time=0.112 ms
ping: sendmsg: Network is down
64 bytes from 192.168.10.8: icmp_seq=17 ttl=64 time=1000 ms
64 bytes from 192.168.10.8: icmp_seq=18 ttl=64 time=0.147 ms

Ding

>>
>> Thanks
>> Ding
>>
>>>
>>>>  		if (!vlan->port->passthru) {
>>>>  			err = dev_uc_add(lowerdev, addr);
>>>>  			if (err)
>>>>
>>>
>>>
>>> .
>>>
>>
>>
> 
> 
> .
> 

Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd_priv is enable

[Vlad Yasevich]

On 06/12/2014 11:10 PM, Ding Tianhong wrote:
> On 2014/6/12 22:24, Vlad Yasevich wrote:
>> On 06/11/2014 09:45 PM, Ding Tianhong wrote:
>>> On 2014/6/10 0:51, Vlad Yasevich wrote:
>>>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>>>
>>>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>>>> will be set to the rar of the lowerdev and no need to set uc list,
>>>>> and when the macvlan's hw address changes, the macvlan should remove
>>>>> the old fwd and rebuild a new fwd for the macvlan.
>>>>>
>>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>>> ---
>>>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>>>  1 file changed, 21 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>>> index 453d55a..67485ab 100644
>>>>> --- a/drivers/net/macvlan.c
>>>>> +++ b/drivers/net/macvlan.c
>>>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>>>  			return -EBUSY;
>>>>>  
>>>>> +		if (vlan->fwd_priv) {
>>>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>>>> +								   vlan->fwd_priv);
>>>>> +			vlan->fwd_priv = NULL;
>>>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>>>> +			ether_addr_copy(dev->dev_addr, addr);
>>>>> +			vlan->fwd_priv =
>>>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>> +								       dev);
>>>>> +			/* If we get a NULL pointer back, or if we get an error
>>>>> +			 * then we should restore the old mac address and fwd.
>>>>> +			 */
>>>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>>>> +				vlan->fwd_priv =
>>>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>> +									       dev);
>>>>> +				return -EINVAL;
>>>>> +			}
>>>>> +			return 0;
>>>>> +		}
>>>>
>>>> Calling del_stations add_station causes all sorts of VMDQ/ring
>>>> operations to happen...  Not sure if we can do that while we have a live
>>>> macvlan/macvtap that is capable of transmitting data.
>>>>
>>>> Wouldn't it be sufficient to have a call to call to update with mac
>>>> filter with the appropriate VMDQ.
>>>>
>>>> John, I defer to you here.  The above looks really heavy-weight and
>>>> I am not sure if its correct.
>>>>
>>>> Thanks
>>>> -vlad
>>>
>>> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
>>> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
>>> work well with the maclvan, so I don't think this solution has problem.
>>
>> Have you tried changing the address while at the same time
>> transmitting data through the macvlan?
>>
>> -vlad
>>
> 
> Yes, I tried, the lowerdev will be closed when calling ixgbe_fwd_del, then the transmitting was broken and about 1 second later,
> the transmitting restored and start to work again.
> 
> 64 bytes from 192.168.10.8: icmp_seq=14 ttl=64 time=0.109 ms
> 64 bytes from 192.168.10.8: icmp_seq=15 ttl=64 time=0.112 ms
> ping: sendmsg: Network is down
> 64 bytes from 192.168.10.8: icmp_seq=17 ttl=64 time=1000 ms
> 64 bytes from 192.168.10.8: icmp_seq=18 ttl=64 time=0.147 ms
> 

Right.  This is what I figured would happen and doesn't happen
with any other device when changing the mac address.

If this behavior is OK with other folks, I'll shut up, but IMO
we shouldn't just correctly update the mac filter and leave the
VMDQs alone.

-vlad

> Ding
> 
>>>
>>> Thanks
>>> Ding
>>>
>>>>
>>>>>  		if (!vlan->port->passthru) {
>>>>>  			err = dev_uc_add(lowerdev, addr);
>>>>>  			if (err)
>>>>>
>>>>
>>>>
>>>> .
>>>>
>>>
>>>
>>
>>
>> .
>>
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd_priv is enable

[Ding Tianhong]

On 2014/6/13 21:30, Vlad Yasevich wrote:
> On 06/12/2014 11:10 PM, Ding Tianhong wrote:
>> On 2014/6/12 22:24, Vlad Yasevich wrote:
>>> On 06/11/2014 09:45 PM, Ding Tianhong wrote:
>>>> On 2014/6/10 0:51, Vlad Yasevich wrote:
>>>>> [.. CC John Fastabend <john.r.fastabend@intel.com> ]
>>>>>
>>>>> On 06/07/2014 03:45 AM, Ding Tianhong wrote:
>>>>>> If lowerdev supports L2 forwarding offload, the macvlan's hw address
>>>>>> will be set to the rar of the lowerdev and no need to set uc list,
>>>>>> and when the macvlan's hw address changes, the macvlan should remove
>>>>>> the old fwd and rebuild a new fwd for the macvlan.
>>>>>>
>>>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>>>> ---
>>>>>>  drivers/net/macvlan.c | 21 +++++++++++++++++++++
>>>>>>  1 file changed, 21 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>>>> index 453d55a..67485ab 100644
>>>>>> --- a/drivers/net/macvlan.c
>>>>>> +++ b/drivers/net/macvlan.c
>>>>>> @@ -523,6 +523,27 @@ static int macvlan_sync_address(struct net_device *dev, unsigned char *addr)
>>>>>>  		if (macvlan_addr_busy(vlan->port, addr))
>>>>>>  			return -EBUSY;
>>>>>>  
>>>>>> +		if (vlan->fwd_priv) {
>>>>>> +			lowerdev->netdev_ops->ndo_dfwd_del_station(lowerdev,
>>>>>> +								   vlan->fwd_priv);
>>>>>> +			vlan->fwd_priv = NULL;
>>>>>> +			ether_addr_copy(dev->perm_addr, dev->dev_addr);
>>>>>> +			ether_addr_copy(dev->dev_addr, addr);
>>>>>> +			vlan->fwd_priv =
>>>>>> +			    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>>> +								       dev);
>>>>>> +			/* If we get a NULL pointer back, or if we get an error
>>>>>> +			 * then we should restore the old mac address and fwd.
>>>>>> +			 */
>>>>>> +			if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>>>>>> +				ether_addr_copy(dev->dev_addr, dev->perm_addr);
>>>>>> +				vlan->fwd_priv =
>>>>>> +				    lowerdev->netdev_ops->ndo_dfwd_add_station(lowerdev,
>>>>>> +									       dev);
>>>>>> +				return -EINVAL;
>>>>>> +			}
>>>>>> +			return 0;
>>>>>> +		}
>>>>>
>>>>> Calling del_stations add_station causes all sorts of VMDQ/ring
>>>>> operations to happen...  Not sure if we can do that while we have a live
>>>>> macvlan/macvtap that is capable of transmitting data.
>>>>>
>>>>> Wouldn't it be sufficient to have a call to call to update with mac
>>>>> filter with the appropriate VMDQ.
>>>>>
>>>>> John, I defer to you here.  The above looks really heavy-weight and
>>>>> I am not sure if its correct.
>>>>>
>>>>> Thanks
>>>>> -vlad
>>>>
>>>> I have used two 82599 nic to test this problem, I modify the ixgbe drivers and set the  L2 forwarding offload default,
>>>> without this patch, when I change the macvlan mac address, the kernel oops, and if I apply this patch, the ixgbe could
>>>> work well with the maclvan, so I don't think this solution has problem.
>>>
>>> Have you tried changing the address while at the same time
>>> transmitting data through the macvlan?
>>>
>>> -vlad
>>>
>>
>> Yes, I tried, the lowerdev will be closed when calling ixgbe_fwd_del, then the transmitting was broken and about 1 second later,
>> the transmitting restored and start to work again.
>>
>> 64 bytes from 192.168.10.8: icmp_seq=14 ttl=64 time=0.109 ms
>> 64 bytes from 192.168.10.8: icmp_seq=15 ttl=64 time=0.112 ms
>> ping: sendmsg: Network is down
>> 64 bytes from 192.168.10.8: icmp_seq=17 ttl=64 time=1000 ms
>> 64 bytes from 192.168.10.8: icmp_seq=18 ttl=64 time=0.147 ms
>>
> 
> Right.  This is what I figured would happen and doesn't happen
> with any other device when changing the mac address.
> 
> If this behavior is OK with other folks, I'll shut up, but IMO
> we shouldn't just correctly update the mac filter and leave the
> VMDQs alone.
> 
> -vlad
> 

Yes, according to your important suggestion, we could further analysis this problem,
and can you explain more about how to fix it better, just like the VMDQ, I am not very
clear about this, thanks for any feedback.

Regards
Ding 

>> Ding
>>
>>>>
>>>> Thanks
>>>> Ding
>>>>
>>>>>
>>>>>>  		if (!vlan->port->passthru) {
>>>>>>  			err = dev_uc_add(lowerdev, addr);
>>>>>>  			if (err)
>>>>>>
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>
>>>
>>> .
>>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 
> .
>