Was there a particular tool or config flag that you used to detect this
error / generate this output?

On 8 September 2014 14:01, Pravin B Shelar <pshe...@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 <joestrin...@nicira.com>
> Signed-off-by: Pravin B Shelar <pshe...@nicira.com>
> ---
>  datapath/datapath.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/datapath/datapath.c b/datapath/datapath.c
> index fae0ac7..d851cab 100644
> --- a/datapath/datapath.c
> +++ b/datapath/datapath.c
> @@ -569,7 +569,7 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb,
> struct genl_info *info)
>
>         rcu_assign_pointer(flow->sf_acts, acts);
>         OVS_CB(packet)->pkt_key = &flow->key;
> -       OVS_CB(skb)->egress_tun_info = NULL;
> +       OVS_CB(packet)->egress_tun_info = NULL;
>         packet->priority = flow->key.phy.priority;
>         packet->mark = flow->key.phy.skb_mark;
>
> --
> 1.9.3
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to