packet execute is setting egress_tun_info in skb->cb, rather
than packet->cb. skb is netlink msg skb. This causes corruption
in netlink skb state stored in skb->cb (NETLINK_CB) which
results in following deadlock in netlink code.
=============================================
[ INFO: possible recursive locking detected ]
3.2.62 #2
---------------------------------------------
handler55/22851 is trying to acquire lock:
(genl_mutex){+.+.+.}, at: [<
ffffffff81471ad7>] genl_lock+0x17/0x20
but task is already holding lock:
(genl_mutex){+.+.+.}, at: [<
ffffffff81471ad7>] genl_lock+0x17/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(genl_mutex);
lock(genl_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by handler55/22851:
#0: (genl_mutex){+.+.+.}, at: [<
ffffffff81471ad7>] genl_lock+0x17/0x20
stack backtrace:
Pid: 22851, comm: handler55 Tainted: G O 3.2.62 #2
Call Trace:
[<
ffffffff81097bb2>] print_deadlock_bug+0xf2/0x100
[<
ffffffff81099b99>] validate_chain+0x579/0x860
[<
ffffffff8109a17c>] __lock_acquire+0x2fc/0x4f0
[<
ffffffff8109aab0>] lock_acquire+0xa0/0x180
[<
ffffffff81519070>] __mutex_lock_common+0x60/0x420
[<
ffffffff8151959a>] mutex_lock_nested+0x4a/0x60
[<
ffffffff81471ad7>] genl_lock+0x17/0x20
[<
ffffffff81471af6>] genl_rcv+0x16/0x40
[<
ffffffff8146ff72>] netlink_unicast+0x2f2/0x310
[<
ffffffff81470159>] netlink_ack+0x109/0x1f0
[<
ffffffff8147030b>] netlink_rcv_skb+0xcb/0xd0
[<
ffffffff81471b05>] genl_rcv+0x25/0x40
[<
ffffffff8146ff72>] netlink_unicast+0x2f2/0x310
[<
ffffffff8147134c>] netlink_sendmsg+0x28c/0x3d0
[<
ffffffff8143375f>] sock_sendmsg+0xef/0x120
[<
ffffffff81435766>] ___sys_sendmsg+0x416/0x430
[<
ffffffff81435949>] __sys_sendmsg+0x49/0x90
[<
ffffffff814359a9>] sys_sendmsg+0x19/0x20
[<
ffffffff8152432b>] system_call_fastpath+0x16/0x1b
Reported-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>