linux-toradex.git/drivers/net/macvlan.c, branch v3.14.57

net: allow macvlans to move to net namespace

2014-10-15T06:36:41+00:00

[ Upstream commit 0d0162e7a33d3710b9604e7c68c0f31f5c457428 ]

I cannot move a macvlan interface created on top of a bonding interface
to a different namespace:

% ip netns add dummy0
% ip link add link bond0 mac0 type macvlan
% ip link set mac0 netns dummy0
RTNETLINK answers: Invalid argument
%

The problem seems to be that commit f9399814927a ("bonding: Don't allow
bond devices to change network namespaces.") sets NETIF_F_NETNS_LOCAL
on bonding interfaces, and commit 797f87f83b60 ("macvlan: fix netdev
feature propagation from lower device") causes macvlan interfaces
to inherit its features from the lower device.

NETIF_F_NETNS_LOCAL should not be inherited from the lower device
by a macvlan.
Patch tested on 3.16.

Signed-off-by: Francesco Ruggeri 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: Initialize vlan_features to turn on offload support.

2014-08-14T01:38:24+00:00

[ Upstream commit 081e83a78db9b0ae1f5eabc2dedecc865f509b98 ]

Macvlan devices do not initialize vlan_features.  As a result,
any vlan devices configured on top of macvlans perform very poorly.
Initialize vlan_features based on the vlan features of the lower-level
device.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: force a list_del() in unregister_netdevice_many()

2014-06-26T19:15:39+00:00

[ Upstream commit 87757a917b0b3c0787e0563c679762152be81312 ]

unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.

See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")

In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: Don't propagate IFF_ALLMULTI changes on down interfaces.

2014-05-31T20:20:37+00:00

[ Upstream commit bbeb0eadcf9fe74fb2b9b1a6fea82cd538b1e556 ]

Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti
overflow on the underlying interface.

Attempting the set IFF_ALLMULTI on the underlying interface would cause an
error and the log message:

"allmulti touches root, set allmulti failed."

Signed-off-by: Peter Christensen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Revert "macvlan : fix checksums error when we are in bridge mode"

2014-05-31T20:20:36+00:00

[ Upstream commit f114890cdf84d753f6b41cd0cc44ba51d16313da ]

This reverts commit 12a2856b604476c27d85a5f9a57ae1661fc46019.
The commit above doesn't appear to be necessary any more as the
checksums appear to be correctly computed/validated.

Additionally the above commit breaks kvm configurations where
one VM is using a device that support checksum offload (virtio) and
the other VM does not.
In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
set.  The packets is forwarded to a macvtap that has offload features
turned off.  Since we use CHECKSUM_UNNECESSARY, the host does does not
update the checksum and thus a bad checksum is passed up to
the guest.

CC: Daniel Lezcano 
CC: Patrick McHardy 
CC: Andrian Nord 
CC: Eric Dumazet 
CC: Michael S. Tsirkin 
CC: Jason Wang 
Signed-off-by: Vlad Yasevich 
Acked-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: Fix lockdep warnings with stacked macvlan devices

2014-05-31T20:20:34+00:00

[ Upstream commit c674ac30c549596295eb0a5af7f4714c0b905b6f ]

Macvlan devices try to avoid stacking, but that's not always
successfull or even desired.  As an example, the following
configuration is perefectly legal and valid:

eth0 <--- macvlan0 <---- vlan0.10 <--- macvlan1

However, this configuration produces the following lockdep
trace:
[  115.620418] ======================================================
[  115.620477] [ INFO: possible circular locking dependency detected ]
[  115.620516] 3.15.0-rc1+ #24 Not tainted
[  115.620540] -------------------------------------------------------
[  115.620577] ip/1704 is trying to acquire lock:
[  115.620604]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_uc_sync+0x3c/0x80
[  115.620686]
but task is already holding lock:
[  115.620723]  (&macvlan_netdev_addr_lock_key){+.....}, at: [] dev_set_rx_mode+0x1e/0x40
[  115.620795]
which lock already depends on the new lock.

[  115.620853]
the existing dependency chain (in reverse order) is:
[  115.620894]
-> #1 (&macvlan_netdev_addr_lock_key){+.....}:
[  115.620935]        [] lock_acquire+0xa2/0x130
[  115.620974]        [] _raw_spin_lock_nested+0x37/0x50
[  115.621019]        [] vlan_dev_set_rx_mode+0x53/0x110 [8021q]
[  115.621066]        [] __dev_set_rx_mode+0x57/0xa0
[  115.621105]        [] dev_set_rx_mode+0x26/0x40
[  115.621143]        [] __dev_open+0xde/0x140
[  115.621174]        [] __dev_change_flags+0x9d/0x170
[  115.621174]        [] dev_change_flags+0x29/0x60
[  115.621174]        [] do_setlink+0x321/0x9a0
[  115.621174]        [] rtnl_newlink+0x51f/0x730
[  115.621174]        [] rtnetlink_rcv_msg+0x95/0x250
[  115.621174]        [] netlink_rcv_skb+0xa9/0xc0
[  115.621174]        [] rtnetlink_rcv+0x2a/0x40
[  115.621174]        [] netlink_unicast+0xf0/0x1c0
[  115.621174]        [] netlink_sendmsg+0x2ff/0x740
[  115.621174]        [] sock_sendmsg+0x8b/0xc0
[  115.621174]        [] ___sys_sendmsg+0x369/0x380
[  115.621174]        [] __sys_sendmsg+0x42/0x80
[  115.621174]        [] SyS_sendmsg+0x12/0x20
[  115.621174]        [] system_call_fastpath+0x16/0x1b
[  115.621174]
-> #0 (&vlan_netdev_addr_lock_key/1){+.....}:
[  115.621174]        [] __lock_acquire+0x1773/0x1a60
[  115.621174]        [] lock_acquire+0xa2/0x130
[  115.621174]        [] _raw_spin_lock_nested+0x37/0x50
[  115.621174]        [] dev_uc_sync+0x3c/0x80
[  115.621174]        [] macvlan_set_mac_lists+0xca/0x110 [macvlan]
[  115.621174]        [] __dev_set_rx_mode+0x57/0xa0
[  115.621174]        [] dev_set_rx_mode+0x26/0x40
[  115.621174]        [] __dev_open+0xde/0x140
[  115.621174]        [] __dev_change_flags+0x9d/0x170
[  115.621174]        [] dev_change_flags+0x29/0x60
[  115.621174]        [] do_setlink+0x321/0x9a0
[  115.621174]        [] rtnl_newlink+0x51f/0x730
[  115.621174]        [] rtnetlink_rcv_msg+0x95/0x250
[  115.621174]        [] netlink_rcv_skb+0xa9/0xc0
[  115.621174]        [] rtnetlink_rcv+0x2a/0x40
[  115.621174]        [] netlink_unicast+0xf0/0x1c0
[  115.621174]        [] netlink_sendmsg+0x2ff/0x740
[  115.621174]        [] sock_sendmsg+0x8b/0xc0
[  115.621174]        [] ___sys_sendmsg+0x369/0x380
[  115.621174]        [] __sys_sendmsg+0x42/0x80
[  115.621174]        [] SyS_sendmsg+0x12/0x20
[  115.621174]        [] system_call_fastpath+0x16/0x1b
[  115.621174]
other info that might help us debug this:

[  115.621174]  Possible unsafe locking scenario:

[  115.621174]        CPU0                    CPU1
[  115.621174]        ----                    ----
[  115.621174]   lock(&macvlan_netdev_addr_lock_key);
[  115.621174]                                lock(&vlan_netdev_addr_lock_key/1);
[  115.621174]                                lock(&macvlan_netdev_addr_lock_key);
[  115.621174]   lock(&vlan_netdev_addr_lock_key/1);
[  115.621174]
 *** DEADLOCK ***

[  115.621174] 2 locks held by ip/1704:
[  115.621174]  #0:  (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1b/0x40
[  115.621174]  #1:  (&macvlan_netdev_addr_lock_key){+.....}, at: [] dev_set_rx_mode+0x1e/0x40
[  115.621174]
stack backtrace:
[  115.621174] CPU: 3 PID: 1704 Comm: ip Not tainted 3.15.0-rc1+ #24
[  115.621174] Hardware name: Hewlett-Packard HP xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010
[  115.621174]  ffffffff82339ae0 ffff880465f79568 ffffffff816ee20c ffffffff82339ae0
[  115.621174]  ffff880465f795a8 ffffffff816e9e1b ffff880465f79600 ffff880465b019c8
[  115.621174]  0000000000000001 0000000000000002 ffff880465b019c8 ffff880465b01230
[  115.621174] Call Trace:
[  115.621174]  [] dump_stack+0x4d/0x66
[  115.621174]  [] print_circular_bug+0x200/0x20e
[  115.621174]  [] __lock_acquire+0x1773/0x1a60
[  115.621174]  [] ? trace_hardirqs_on_caller+0xb2/0x1d0
[  115.621174]  [] lock_acquire+0xa2/0x130
[  115.621174]  [] ? dev_uc_sync+0x3c/0x80
[  115.621174]  [] _raw_spin_lock_nested+0x37/0x50
[  115.621174]  [] ? dev_uc_sync+0x3c/0x80
[  115.621174]  [] dev_uc_sync+0x3c/0x80
[  115.621174]  [] macvlan_set_mac_lists+0xca/0x110 [macvlan]
[  115.621174]  [] __dev_set_rx_mode+0x57/0xa0
[  115.621174]  [] dev_set_rx_mode+0x26/0x40
[  115.621174]  [] __dev_open+0xde/0x140
[  115.621174]  [] __dev_change_flags+0x9d/0x170
[  115.621174]  [] dev_change_flags+0x29/0x60
[  115.621174]  [] ? mem_cgroup_bad_page_check+0x21/0x30
[  115.621174]  [] do_setlink+0x321/0x9a0
[  115.621174]  [] ? __lock_acquire+0x37c/0x1a60
[  115.621174]  [] rtnl_newlink+0x51f/0x730
[  115.621174]  [] ? rtnl_newlink+0xe9/0x730
[  115.621174]  [] rtnetlink_rcv_msg+0x95/0x250
[  115.621174]  [] ? trace_hardirqs_on+0xd/0x10
[  115.621174]  [] ? rtnetlink_rcv+0x1b/0x40
[  115.621174]  [] ? rtnetlink_rcv+0x40/0x40
[  115.621174]  [] netlink_rcv_skb+0xa9/0xc0
[  115.621174]  [] rtnetlink_rcv+0x2a/0x40
[  115.621174]  [] netlink_unicast+0xf0/0x1c0
[  115.621174]  [] netlink_sendmsg+0x2ff/0x740
[  115.621174]  [] sock_sendmsg+0x8b/0xc0
[  115.621174]  [] ? might_fault+0x5f/0xb0
[  115.621174]  [] ? might_fault+0xa8/0xb0
[  115.621174]  [] ? might_fault+0x5f/0xb0
[  115.621174]  [] ? verify_iovec+0x5e/0xe0
[  115.621174]  [] ___sys_sendmsg+0x369/0x380
[  115.621174]  [] ? __do_page_fault+0x11d/0x570
[  115.621174]  [] ? up_read+0x1f/0x40
[  115.621174]  [] ? __do_page_fault+0x214/0x570
[  115.621174]  [] ? mntput_no_expire+0x6b/0x1c0
[  115.621174]  [] ? mntput_no_expire+0x17/0x1c0
[  115.621174]  [] ? mntput+0x24/0x40
[  115.621174]  [] __sys_sendmsg+0x42/0x80
[  115.621174]  [] SyS_sendmsg+0x12/0x20
[  115.621174]  [] system_call_fastpath+0x16/0x1b

Fix this by correctly providing macvlan lockdep class.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: Add support for 'always_on' offload features

2014-03-03T21:43:56+00:00

Macvlan currently inherits all of its features from the lower
device. When lower device disables offload support, this causes
macvlan to disable offload support as well. This causes
performance regression when using macvlan/macvtap in bridge
mode.

It can be easily demonstrated by creating 2 namespaces using
macvlan in bridge mode and running netperf between them:

MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.0.1 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 20.00 1204.61

To restore the performance, we add software offload features
to the list of "always_on" features for macvlan. This way
when a namespace or a guest using macvtap initially sends a
packet, this packet will not be segmented at macvlan level.
It will only be segmented when macvlan sends the packet
to the lower device.

87380 16384 16384 20.00 5507.35

Fixes: 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 (macvtap: Add support of packet capture on macvtap device.)
Fixes: 797f87f83b60685ff8a13fa0572d2f10393c50d3 (macvlan: fix netdev feature propagation from lower device)
CC: Florian Westphal
CC: Christian Borntraeger
CC: Jason Wang
CC: Michael S. Tsirkin
Tested-by: Christian Borntraeger
Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller

macvlan: unregister net device when netdev_upper_dev_link() fails

2014-02-13T22:08:28+00:00

rtnl_newlink() doesn't unregister it for us on failure.

Cc: Patrick McHardy 
Cc: David S. Miller 
Signed-off-by: Cong Wang 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2014-01-14T22:42:42+00:00

net: core: explicitly select a txq before doing l2 forwarding

2014-01-10T18:23:08+00:00

Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
will cause several issues:

- NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
  instead of lower device which misses the necessary txq synchronization for
  lower device such as txq stopping or frozen required by dev watchdog or
  control path.
- dev_hard_start_xmit() was called with NULL txq which bypasses the net device
  watchdog.
- dev_hard_start_xmit() does not check txq everywhere which will lead a crash
  when tso is disabled for lower device.

Fix this by explicitly introducing a new param for .ndo_select_queue() for just
selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
forwarding transmission.

With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
dev_queue_xmit() to do the transmission.

In the future, it was also required for macvtap l2 forwarding support since it
provides a necessary synchronization method.

Cc: John Fastabend 
Cc: Neil Horman 
Cc: e1000-devel@lists.sourceforge.net
Signed-off-by: Jason Wang 
Acked-by: Neil Horman 
Acked-by: John Fastabend 
Signed-off-by: David S. Miller