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: <1411161451.26859.32.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Fri, 19 Sep 2014 14:17:31 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Francesco Ruggeri <fruggeri@...stanetworks.com>
Cc:	netdev@...r.kernel.org, fruggeri@...sta.com, davem@...emloft.net,
	herbert@...dor.apana.org.au
Subject: Re: cannot ARP macvlan on top of bonding device

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 ?



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