netdev - Re: Query on a lockdep issue in neigh

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 14 Sep 2011 11:36:57 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Murali raja Muniraju <murali.rajam@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Query on a lockdep issue in neigh_lookup

Le mardi 13 septembre 2011 à 16:11 -0700, Murali raja Muniraju a écrit :
> Hi,
>    I see a potential deadlock situation on the kernel 2.6.34. Has this
> been fixed in the later version of the kernel.

Hmm, is it a pristine 2.6.34, or something you modified ?

Please dont ask us to debug your changes, without even making this clear
at the very beginning.

netdev is not at your disposal.

> 
> I see that one after holding the neigh_lookup, one can acquire the
> lock for rt_hash_locks
> 
> But there is a situation while freed skb's in dst_release while
> holding the rt_hash_locks, neigh_lookup can be called which tries to
> acquire its lock.
> 

how so ? Following 2.6.34 code is 100% safe.

void dst_release(struct dst_entry *dst)
{
        if (dst) {
               int newrefcnt;

               smp_mb__before_atomic_dec();
               newrefcnt = atomic_dec_return(&dst->__refcnt);
               WARN_ON(newrefcnt < 0);
        }
}


> This seems to be a deadlock candidate.
> 

Only because of some alien patch.

> Thanks,
> Murali
> 
> Below if the scenario found by lockdep on a debug kernel during the
> kernel bootup.
> 
>     [   92.245713] =======================================================
>  [   92.246640] [ INFO: possible circular locking dependency detected ]
>  [   92.246640] 2.6.34-dbg-2011082906 #1
>  [   92.246640] -------------------------------------------------------
>  [   92.246640] swapper/0 is trying to acquire lock:
>  [   92.246640]  (&tbl->lock){++--..}, at: [<ffffffff81553a22>]
> neigh_lookup+0x42/0xd0
>  [   92.246640]
>  [   92.246640] but task is already holding lock:
>  [   92.246640]  (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff815798e0>] rt_intern_hash+0xd0/0x880
>  [   92.246640]
>  [   92.246640] which lock already depends on the new lock.
>  [   92.246640]
>  [   92.246640]
>  [   92.246640] the existing dependency chain (in reverse order) is:
>  [   92.246640]
>  [   92.246640] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
>  [   92.246640]        [<ffffffff810e7700>] __lock_acquire+0xe30/0x1190
>  [   92.246640]        [<ffffffff810e7af3>] lock_acquire+0x93/0x120
>  [   92.246640]        [<ffffffff815ed266>] _raw_spin_lock_bh+0x36/0x50
>  [   92.246640]        [<ffffffff81576a26>] rt_dst_release+0x66/0xc0

I cant see rt_dst_release() in 2.6.34




>  [   92.246640]        [<ffffffff8155194c>] dst_release+0x5c/0x90
>  [   92.246640]        [<ffffffff8153aef5>] skb_release_head_state+0x95/0xd0
>  [   92.246640]        [<ffffffff8153ad06>] __kfree_skb+0x16/0xa0
>  [   92.246640]        [<ffffffff8153ae12>] kfree_skb+0x42/0x90
>  [   92.246640]        [<ffffffff81552fae>] __neigh_event_send+0x11e/0x1d0
>  [   92.246640]        [<ffffffff81553193>] neigh_resolve_output+0x133/0x2f0
>  [   92.246640]        [<ffffffff81584742>] ip_output+0x2c2/0x3a0
>  [   92.246640]        [<ffffffff8158291d>] ip_local_out+0xad/0xc0
>  [   92.246640]        [<ffffffff81582cc0>] ip_send_reply+0x290/0x340
>  [   92.246640]        [<ffffffff815a3ba1>] tcp_v4_send_reset+0x1a1/0x310
>  [   92.246640]        [<ffffffff815a7b04>] tcp_v4_rcv+0x314/0x9b0
>  [   92.246640]        [<ffffffff8157e344>] ip_local_deliver_finish+0xf4/0x200
>  [   92.246640]        [<ffffffff8157e4e0>] ip_local_deliver+0x90/0xa0
>  [   92.246640]        [<ffffffff8157dbf1>] ip_rcv_finish+0x111/0x460
>  [   92.246640]        [<ffffffff8157e17d>] ip_rcv+0x23d/0x310
>  [   92.246640]        [<ffffffff81549144>] __netif_receive_skb+0x2d4/0x570
>  [   92.246640]        [<ffffffff81549620>] netif_receive_skb+0xb0/0xc0
>  [   92.246640]        [<ffffffff81549d28>] napi_gro_receive+0x148/0x180
>  [   92.246640]        [<ffffffffa0066aba>]


--
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