[ovs-dev] [PATCH] datapath: Set packet egress_tun_info.

Pravin Shelar pshelar at nicira.com
Mon Sep 8 17:44:55 UTC 2014


On Sun, Sep 7, 2014 at 11:26 PM, Joe Stringer <joestringer at nicira.com> wrote:
>
>
> On 8 September 2014 14:01, Pravin B Shelar <pshelar at nicira.com> wrote:
>>
>> 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 at nicira.com>
>> Signed-off-by: Pravin B Shelar <pshelar at nicira.com>
>
>
> Thanks for tracking this down, it fixes the problem I was having.
>
> Acked-by: Joe Stringer <joestringer at nicira.com>


I pushed it to master.
Thanks.



More information about the dev mailing list