linux-toradex.git/include/linux/if_macvlan.h, branch v3.14.46

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: unify macvlan_pcpu_stats and vlan_pcpu_stats

2014-01-05T01:11:33+00:00

They are same, so unify them as one; since macvlan is a kind of vlan,
vlan_pcpu_stats should be a proper name for vlan and macvlan.

Signed-off-by: Li RongQing 
Signed-off-by: David S. Miller

macvlan: make start_xmit local

2013-12-28T06:20:46+00:00

Only used in one file, no need to expose

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

macvlan: Remove custom recieve and forward handlers

2013-12-12T18:38:39+00:00

Since now macvlan and macvtap use the same receive and
forward handlers, we can remove them completely and use
netif_rx and dev_forward_skb() directly.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

macvlan: introduce macvlan_dev_real_dev() helper function

2013-11-15T22:55:48+00:00

Introduce helper function macvlan_dev_real_dev which returns the
underlying device of a macvlan device, similar to vlan_dev_real_dev()
for 802.1q VLAN devices.

v2: IFF_MACVLAN flag and equivalent of is_macvlan_dev() were
introduced in the meantime

v3: do BUG() if compiled without macvlan support

Signed-off-by: Michal Kubecek 
Signed-off-by: David S. Miller

net: Add layer 2 hardware acceleration operations for macvlan devices

2013-11-08T00:11:41+00:00

Add a operations structure that allows a network interface to export
the fact that it supports package forwarding in hardware between
physical interfaces and other mac layer devices assigned to it (such
as macvlans). This operaions structure can be used by virtual mac
devices to bypass software switching so that forwarding can be done
in hardware more efficiently.

Signed-off-by: John Fastabend 
Signed-off-by: Neil Horman 
CC: Andy Gospodarek 
CC: "David S. Miller" 
Signed-off-by: David S. Miller

macvtap: Let TUNSETOFFLOAD actually controll offload features.

2013-06-25T23:44:56+00:00

When the user issues TUNSETOFFLOAD ioctl, macvtap does not do
anything other then to verify arguments.  This patch adds
functionality to allow users to actually control offload features.
NETIF_F_GSO and NETIF_F_GRO are always on, but the rest of the
features can be controlled.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

macvtap: slient sparse warnings

2013-06-13T08:23:11+00:00

This patch silents the following sparse warnings:

drivers/net/macvtap.c:98:9: warning: incorrect type in assignment (different
address spaces)
drivers/net/macvtap.c:98:9:    expected struct macvtap_queue *
drivers/net/macvtap.c:98:9:    got struct macvtap_queue [noderef]
*
drivers/net/macvtap.c:120:9: warning: incorrect type in assignment (different
address spaces)
drivers/net/macvtap.c:120:9:    expected struct macvtap_queue *
drivers/net/macvtap.c:120:9:    got struct macvtap_queue [noderef]
*
drivers/net/macvtap.c:151:22: error: incompatible types in comparison expression
(different address spaces)
drivers/net/macvtap.c:233:23: error: incompatible types in comparison expression
(different address spaces)
drivers/net/macvtap.c:243:23: error: incompatible types in comparison expression
(different address spaces)
drivers/net/macvtap.c:247:15: error: incompatible types in comparison expression
(different address spaces)
  CC [M]  drivers/net/macvtap.o
drivers/net/macvlan.c:232:24: error: incompatible types in comparison expression
(different address spaces)

Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller

macvtap: add TUNSETQUEUE ioctl

2013-06-08T06:49:09+00:00

This patch adds TUNSETQUEUE ioctl to let userspace can temporarily disable or
enable a queue of macvtap. This is used to be compatible at API layer of tuntap
to simplify the userspace to manage the queues. This is done through introducing
a linked list to track all taps while using vlan->taps array to only track
active taps.

Signed-off-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller

macvlan: change the max number of queues to 16

2013-06-08T06:49:09+00:00

Macvtap should be at least compatible with tap, so change the max number to 16.

Signed-off-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller