netdev - Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes when fwd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Jun 2014 09:30:25 -0400
From:	Vlad Yasevich <vyasevich@...il.com>
To:	Ding Tianhong <dingtianhong@...wei.com>, vyasevic@...hat.com,
	kaber@...sh.net, davem@...emloft.net, edumazet@...gle.com,
	makita.toshiaki@....ntt.co.jp
CC:	netdev@...r.kernel.org, John Fastabend <john.r.fastabend@...el.com>
Subject: Re: [PATCH net-next v2 RESEND 1/4] macvlan: support mac address changes
 when fwd_priv is enable

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@...el.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@...wei.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html