vlan: don't allow to add VLAN on VLAN device
Subsystems (2)
PATCH RESEND 1/1 vlan: don't allow to add VLAN on VLAN device
I run these steps:
modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 20
ifconfig eth2 xx.xx.xx.xx
then the Call Trace happened:
[32524.386288] =============================================
[32524.386293] [ INFO: possible recursive locking detected ]
[32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G O
[32524.386302] ---------------------------------------------
[32524.386306] ifconfig/3103 is trying to acquire lock:
[32524.386310] (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
[32524.386326]
[32524.386326] but task is already holding lock:
[32524.386330] (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
[32524.386341]
[32524.386341] other info that might help us debug this:
[32524.386345] Possible unsafe locking scenario:
[32524.386345]
[32524.386350] CPU0
[32524.386352] ----
[32524.386354] lock(&vlan_netdev_addr_lock_key/1);
[32524.386359] lock(&vlan_netdev_addr_lock_key/1);
[32524.386364]
[32524.386364] *** DEADLOCK ***
[32524.386364]
[32524.386368] May be due to missing lock nesting notation
[32524.386368]
[32524.386373] 2 locks held by ifconfig/3103:
[32524.386376] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff81431d42>] rtnl_lock+0x12/0x20
[32524.386387] #1: (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
[32524.386398]
[32524.386398] stack backtrace:
[32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G O 3.14.0-rc2-0.7-default+ #35
[32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[32524.386414] ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8
[32524.386421] ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0
[32524.386428] 000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000
[32524.386435] Call Trace:
[32524.386441] [<ffffffff814f68a2>] dump_stack+0x6a/0x78
[32524.386448] [<ffffffff810a35fb>] __lock_acquire+0x7ab/0x1940
[32524.386454] [<ffffffff810a323a>] ? __lock_acquire+0x3ea/0x1940
[32524.386459] [<ffffffff810a4874>] lock_acquire+0xe4/0x110
[32524.386464] [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
[32524.386471] [<ffffffff814fc07a>] _raw_spin_lock_nested+0x2a/0x40
[32524.386476] [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
[32524.386481] [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
[32524.386489] [<ffffffffa0500cab>] vlan_dev_set_rx_mode+0x2b/0x50 [8021q]
[32524.386495] [<ffffffff8141addf>] __dev_set_rx_mode+0x5f/0xb0
[32524.386500] [<ffffffff8141af8b>] dev_set_rx_mode+0x2b/0x40
[32524.386506] [<ffffffff8141b3cf>] __dev_open+0xef/0x150
[32524.386511] [<ffffffff8141b177>] __dev_change_flags+0xa7/0x190
[32524.386516] [<ffffffff8141b292>] dev_change_flags+0x32/0x80
[32524.386524] [<ffffffff8149ca56>] devinet_ioctl+0x7d6/0x830
[32524.386532] [<ffffffff81437b0b>] ? dev_ioctl+0x34b/0x660
[32524.386540] [<ffffffff814a05b0>] inet_ioctl+0x80/0xa0
[32524.386550] [<ffffffff8140199d>] sock_do_ioctl+0x2d/0x60
[32524.386558] [<ffffffff81401a52>] sock_ioctl+0x82/0x2a0
[32524.386568] [<ffffffff811a7123>] do_vfs_ioctl+0x93/0x590
[32524.386578] [<ffffffff811b2705>] ? rcu_read_lock_held+0x45/0x50
[32524.386586] [<ffffffff811b39e5>] ? __fget_light+0x105/0x110
[32524.386594] [<ffffffff811a76b1>] SyS_ioctl+0x91/0xb0
[32524.386604] [<ffffffff815057e2>] system_call_fastpath+0x16/0x1b========================================================================
The reason is that if add vlan on vlan dev, the vlan dev will create vlan_info, then the notification will let the real dev to run dev_set_rx_mode() and hold netif_addr_lock, and then the real dev will call ndo_set_rx_mode(), if the real dev is vlan dev, the ndo_set_rx_mode() will hold netif_addr_lock again, so deadlock happened.
Don't allow to add vlan on vlan dev to fix this problem.
--- net/8021q/vlan.c | 5 +++++ 1 file changed, 5 insertions(+)
net/8021q/vlan.c +5 -0
@@ -132,6 +132,11 @@ int vlan_check_real_dev(struct net_device *real_dev,return -EOPNOTSUPP ; } +if (real_dev->priv_flags &IFF_802_1Q_VLAN ) { +pr_info ("Don't add VLAN on VLAN device %s\n" , name); +return -EOPNOTSUPP ; + } +if (vlan_find_dev (real_dev, protocol, vlan_id) !=NULL )return -EEXIST ;
Signature · 1 line
1.8.0
Quoted 9 lines · Ding Tianhong
I run these steps:
modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 20
ifconfig eth2 xx.xx.xx.xxthen the Call Trace happened:
[...]
Quoted 8 lines
========================================================================
The reason is that if add vlan on vlan dev, the vlan dev will create
vlan_info, then the notification will let the real dev to rundev_set_rx_mode()and holdnetif_addr_lock, and then the real dev will callndo_set_rx_mode(), if the real dev is vlan dev, thendo_set_rx_mode()will holdnetif_addr_lockagain, so deadlock happened.
Quoted 4 lines
Don't allow to add vlan on vlan dev to fix this problem.
Signed-off-by Ding Tianhong <[email protected]>---
I'm not sure we can just disable stacked vlans. There might be something using them today and they have worked in the past. Lets try to find a better fix.
.John
Quoted 23 lines · John Fastabend
Quoted 9 lines · Ding Tianhong
I run these steps:
modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 20
ifconfig eth2 xx.xx.xx.xxthen the Call Trace happened:
[...]
Quoted 10 lines
========================================================================
The reason is that if add vlan on vlan dev, the vlan dev will create
vlan_info, then the notification will let the real dev to rundev_set_rx_mode()and holdnetif_addr_lock, and then the real dev will callndo_set_rx_mode(), if the real dev is vlan dev, thendo_set_rx_mode()will holdnetif_addr_lockagain, so deadlock happened.Don't allow to add vlan on vlan dev to fix this problem.
Quoted 8 lines
Quoted 2 lines
Signed-off-by Ding Tianhong <[email protected]>---
I'm not sure we can just disable stacked vlans. There might be something using them today and they have worked in the past. Lets try to find a better fix.
.John
Yes, maybe I miss something, can you gave me a scene that the use of eth2.20.30? the device is created from vlan device eth2.20, than I will find a better way to fix it.
Thanks
Ding
Quoted 7 lines
Signature · 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2014-02-27 21:26 GMT-08:00 Ding Tianhong <[email protected]>:
Quoted 27 lines · John Fastabend
Quoted 26 lines · Ding Tianhong
Quoted 9 lines
I run these steps:
modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 20
ifconfig eth2 xx.xx.xx.xxthen the Call Trace happened:
[...]
Quoted 12 lines
========================================================================
The reason is that if add vlan on vlan dev, the vlan dev will create
vlan_info, then the notification will let the real dev to rundev_set_rx_mode()and holdnetif_addr_lock, and then the real dev will callndo_set_rx_mode(), if the real dev is vlan dev, thendo_set_rx_mode()will holdnetif_addr_lockagain, so deadlock happened.Don't allow to add vlan on vlan dev to fix this problem.
Signed-off-by Ding Tianhong <[email protected]>---
Quoted 8 lines
Quoted 5 lines
I'm not sure we can just disable stacked vlans. There might be something using them today and they have worked in the past. Lets try to find a better fix.
.John
Yes, maybe I miss something, can you gave me a scene that the use of eth2.20.30? the device is created from vlan device eth2.20, than I will find a better way to fix it.
Is not QinQ (802.1ad) such as case [1]?
[1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ad227ff89a7e6f05d07cd0acfd95ed3a24450ca
--
Florian
Quoted 34 lines · Florian Fainelli
2014-02-27 21:26 GMT-08:00 Ding Tianhong <[email protected]>:
Quoted 33 lines · John Fastabend
Quoted 31 lines · Ding Tianhong
Quoted 9 lines
I run these steps:
modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 20
ifconfig eth2 xx.xx.xx.xxthen the Call Trace happened:
[...]
Quoted 8 lines
========================================================================
The reason is that if add vlan on vlan dev, the vlan dev will create
vlan_info, then the notification will let the real dev to rundev_set_rx_mode()and holdnetif_addr_lock, and then the real dev will callndo_set_rx_mode(), if the real dev is vlan dev, thendo_set_rx_mode()will holdnetif_addr_lockagain, so deadlock happened.Quoted 4 lines
Don't allow to add vlan on vlan dev to fix this problem.
Signed-off-by Ding Tianhong <[email protected]>---
I'm not sure we can just disable stacked vlans. There might be something using them today and they have worked in the past. Lets try to find a better fix.
.John
Quoted 10 lines
Quoted 2 lines
Yes, maybe I miss something, can you gave me a scene that the use of eth2.20.30? the device is created from vlan device eth2.20, than I will find a better way to fix it.
Is not QinQ (802.1ad) such as case [1]?
[1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ad227ff89a7e6f05d07cd0acfd95ed3a24450ca
--
Florian
Yep, thanks a lot.
Ding
Quoted 21 lines · John Fastabend
Quoted 9 lines · Ding Tianhong
I run these steps:
modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 20
ifconfig eth2 xx.xx.xx.xxthen the Call Trace happened:
[...]
Quoted 8 lines
========================================================================
The reason is that if add vlan on vlan dev, the vlan dev will create
vlan_info, then the notification will let the real dev to rundev_set_rx_mode()and holdnetif_addr_lock, and then the real dev will callndo_set_rx_mode(), if the real dev is vlan dev, thendo_set_rx_mode()will holdnetif_addr_lockagain, so deadlock happened.
Quoted 8 lines
Quoted 4 lines
Don't allow to add vlan on vlan dev to fix this problem.
Signed-off-by Ding Tianhong <[email protected]>---
I'm not sure we can just disable stacked vlans. There might be something using them today and they have worked in the past. Lets try to find a better fix.
I don't think there's any deadlock possible here. We try to acquire the addr_list_lock for eth2.20, then the addr_list_lock for eth2. We never try to acquire them in the opposite order. The fix would involve telling lockdep about lock ordering between stacked net_devices (I have no idea how that's done).
Ben.
Signature · 3 lines
Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong.
Quoted 31 lines · Ben Hutchings
Quoted 21 lines · John Fastabend
Quoted 9 lines · Ding Tianhong
I run these steps:
modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 20
ifconfig eth2 xx.xx.xx.xxthen the Call Trace happened:
[...]
Quoted 8 lines
========================================================================
The reason is that if add vlan on vlan dev, the vlan dev will create
vlan_info, then the notification will let the real dev to rundev_set_rx_mode()and holdnetif_addr_lock, and then the real dev will callndo_set_rx_mode(), if the real dev is vlan dev, thendo_set_rx_mode()will holdnetif_addr_lockagain, so deadlock happened.Quoted 8 lines
Quoted 4 lines
Don't allow to add vlan on vlan dev to fix this problem.
Signed-off-by Ding Tianhong <[email protected]>---
I'm not sure we can just disable stacked vlans. There might be something using them today and they have worked in the past. Lets try to find a better fix.
Quoted 8 lines
I don't think there's any deadlock possible here. We try to acquire the
addr_list_lockfor eth2.20, then theaddr_list_lockfor eth2. We never try to acquire them in the opposite order. The fix would involve telling lockdep about lock ordering between stackednet_devices(I have no idea how that's done).Ben.
Yep, it is a warning when the lockdep is open, I review the code again, and the deadlock would not happen, just the same class of locks twice, so I think it is not a bugfix, just like a optimization.
Regards
Ding