[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20151028065751.4de6201f@samsung9>
Date: Wed, 28 Oct 2015 06:57:51 +0900
From: Stephen Hemminger <stephen@...workplumber.org>
To: netdev@...r.kernel.org
Subject: Fw: [Bug 106711] New: VXLAN: RTNL assertion failed at
net/core/net_namespace.c:187
Begin forwarded message:
Date: Tue, 27 Oct 2015 14:05:08 +0000
From: "bugzilla-daemon@...zilla.kernel.org" <bugzilla-daemon@...zilla.kernel.org>
To: "shemminger@...ux-foundation.org" <shemminger@...ux-foundation.org>
Subject: [Bug 106711] New: VXLAN: RTNL assertion failed at net/core/net_namespace.c:187
https://bugzilla.kernel.org/show_bug.cgi?id=106711
Bug ID: 106711
Summary: VXLAN: RTNL assertion failed at
net/core/net_namespace.c:187
Product: Networking
Version: 2.5
Kernel Version: 4.1.10
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: shemminger@...ux-foundation.org
Reporter: tuomo.turunen@...ia.com
Regression: No
VXLAN packet receiving triggers ASSERT_RTNL() assertion failure if VXLAN
transport interface is in different network namespace than the VXLAN interface
itself:
[ 38.891092] RTNL: assertion failed at
/build/distro/work/shared/linux-stable-30bb3a6af25f17c356252ac6cfbfd3ec04ae1a56/net/core/net_namespace.c
(187)
[ 38.892738] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted
4.1.10-pc64-distro.git-v1.14 #1
[ 38.893720] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[ 38.894933] ffff8800ba372280 ffff88013ab3f808 ffffffff8078a62a
ffff88013fc110f8
[ 38.896059] 00000000ffffffff ffff88013ab3f838 ffffffff8068b7b5
ffff88013a7a3600
[ 38.897172] ffff8800bbbc2c00 ffff8801381262a0 ffff880138126300
ffff88013ab3f848
[ 38.898354] Call Trace:
[ 38.898763] [<ffffffff8078a62a>] dump_stack+0x45/0x57
[ 38.899436] [<ffffffff8068b7b5>] __peernet2id+0xa5/0xb0
[ 38.900099] [<ffffffff8068b7d8>] peernet2id+0x18/0x30
[ 38.900756] [<ffffffffa003a2ba>] vxlan_fdb_info+0xfa/0x360 [vxlan]
[ 38.901526] [<ffffffff80682e57>] ? __alloc_skb+0x97/0x1e0
[ 38.902216] [<ffffffffa003a592>] vxlan_fdb_notify+0x72/0x100 [vxlan]
[ 38.902994] [<ffffffffa003b426>] vxlan_fdb_create+0x136/0x370 [vxlan]
[ 38.903797] [<ffffffffa003bf95>] vxlan_snoop+0x1c5/0x1d0 [vxlan]
[ 38.904551] [<ffffffffa003deba>] vxlan_rcv+0x35a/0x5c0 [vxlan]
[ 38.905393] [<ffffffff8069d48f>] ? dst_alloc+0x4f/0x180
[ 38.906165] [<ffffffffa003c208>] vxlan_udp_encap_recv+0x108/0x390 [vxlan]
[ 38.907111] [<ffffffffa003c100>] ? vxlan_encap_bypass.isra.37+0x160/0x160
[vxlan]
[ 38.908278] [<ffffffff806ff81b>] udp_queue_rcv_skb+0x35b/0x450
[ 38.909119] [<ffffffff806fff26>] __udp4_lib_rcv+0x126/0x750
[ 38.909915] [<ffffffff80700a7a>] udp_rcv+0x1a/0x20
[ 38.910640] [<ffffffff806ce5ae>] ip_local_deliver_finish+0xae/0x230
[ 38.911529] [<ffffffff806ce91a>] ip_local_deliver+0x9a/0xb0
[ 38.912341] [<ffffffff806ce218>] ip_rcv_finish+0x88/0x370
[ 38.913277] [<ffffffff806cec0f>] ip_rcv+0x2df/0x3c0
[ 38.914000] [<ffffffff80289343>] ? load_balance+0x233/0xa20
[ 38.914807] [<ffffffff80694b93>] __netif_receive_skb_core+0x6e3/0xa20
[ 38.915714] [<ffffffff8027661c>] ? update_rq_clock.part.81+0x1c/0x40
[ 38.916613] [<ffffffff80694eed>] __netif_receive_skb+0x1d/0x70
[ 38.917461] [<ffffffff80695d42>] process_backlog+0xc2/0x170
[ 38.918291] [<ffffffff806954ba>] net_rx_action+0x20a/0x340
[ 38.919123] [<ffffffff8025702f>] __do_softirq+0xef/0x320
[ 38.919959] [<ffffffff80257285>] run_ksoftirqd+0x25/0x60
[ 38.920764] [<ffffffff80273ecf>] smpboot_thread_fn+0x12f/0x190
[ 38.921605] [<ffffffff80273da0>] ? sort_range+0x30/0x30
[ 38.922384] [<ffffffff80270bb9>] kthread+0xc9/0xe0
[ 38.923104] [<ffffffff80270af0>] ? kthread_create_on_node+0x180/0x180
[ 38.923994] [<ffffffff80790e02>] ret_from_fork+0x42/0x70
[ 38.924772] [<ffffffff80270af0>] ? kthread_create_on_node+0x180/0x180
Seems to me that peernet2id() function should not be called while receiving
packets or then peernet2id() function should not use rtnl lock.
The issue can be reproduced with following configuration + ping (one host is
enough, real network is not needed):
ip netns add ns0
ip netns exec ns0 ip link set lo up
ip netns add ns1
ip netns exec ns1 ip link set lo up
ip netns add ns2
ip netns exec ns2 ip link set lo up
ip netns add ns3
ip netns exec ns3 ip link set lo up
ip link add type veth
ip link set veth0 netns ns0
ip netns exec ns0 ip link set veth0 up
ip netns exec ns0 ip addr add 10.0.0.1/24 dev veth0
ip link set veth1 netns ns1
ip netns exec ns1 ip link set veth1 up
ip netns exec ns1 ip addr add 10.0.0.2/24 dev veth1
ip netns exec ns0 ip link add name vxlan0 type vxlan id 1000 group 224.0.0.1
local 10.0.0.1 dev veth0 learning
ip netns exec ns0 ip link set vxlan0 netns ns2
ip netns exec ns2 ip link set vxlan0 up
ip netns exec ns2 ip addr add 20.0.0.1/24 dev vxlan0
ip netns exec ns1 ip link add name vxlan1 type vxlan id 1000 group 224.0.0.1
local 10.0.0.2 dev veth1 learning
ip netns exec ns1 ip link set vxlan1 netns ns3
ip netns exec ns3 ip link set vxlan1 up
ip netns exec ns3 ip addr add 20.0.0.2/24 dev vxlan1
ip netns exec ns2 ping 20.0.0.1
--
You are receiving this mail because:
You are the assignee for the bug.
--
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
Powered by blists - more mailing lists