netdev - Re: cannot ARP macvlan on top of bonding device

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]

Message-ID: <CA+HUmGi16QV2r7BuJYQWBckUG=oCe04JwJQFAyj=LihL=Rj5Kg@mail.gmail.com>
Date:	Fri, 19 Sep 2014 14:35:48 -0700
From:	Francesco Ruggeri <fruggeri@...sta.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Francesco Ruggeri <fruggeri@...stanetworks.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	herbert@...dor.apana.org.au, nicolas.dichtel@...nd.com
Subject: Re: cannot ARP macvlan on top of bonding device

On Fri, Sep 19, 2014 at 2:17 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Fri, 2014-09-19 at 14:00 -0700, Francesco Ruggeri wrote:
>> [Resending with correct date]
>>
>> Ping in the following test fails:
>>
>> # Create veth pair v1 v2
>> ip link add v1 type veth peer name v2
>>
>> # Stack macvlan on top of bonding device on top of v1
>> ip link set v1 up
>> ip link add bond1 type bond
>> ip link set bond1 up
>> ifenslave bond1 v1
>> ip link add link bond1 name mac1 type macvlan mode bridge
>> ip link set mac1 up
>> ifconfig mac1 1.2.3.1/24
>>
>> # Move v2 to namespace dummy2 and ping v1
>> ip netns add dummy2
>> ip link set v2 netns dummy2
>> ip netns exec dummy2 bash
>> ip link set lo up
>> ip link set v2 up
>> ifconfig v2 1.2.3.2/24
>> ping 1.2.3.1 -c 5
>>
>> # Clean up
>> exit
>> ip netns del dummy2
>> ip link del bond
>>
>> It passes on older releases.
>> The problem is that txqueuelen in bond1 is 0, and ARP requests are dropped in macvlan_broadcast_enqueue at:
>>
>>         if (skb_queue_len(&port->bc_queue) < skb->dev->tx_queue_len) {
>>                 __skb_queue_tail(&port->bc_queue, nskb);
>>                 err = 0;
>>         }
>>
>> where
>> port->dev = skb->dev = "bond1"
>> skb_queue_len(&port->bc_queue) = skb->dev->tx_queue_len = 0
>>
>> macvlan_broadcast_enqueue was introduced in 412ca1550 (macvlan: Move broadcasts into a work queue).
>>
>> Why are we using tx_queue_len to limit an rx queue?
>
> You're right, we probably should use netdev_max_backlog instead.
>
> Please send a formal patch ?
>
>
>

After sending my email I noticed that Nicolas Dichtel already
submitted a similar patch at
http://marc.info/?l=linux-netdev&m=141094132726614&w=2

Francesco
--
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