Re: net: deadlock between ip_expire/sch_direct_xmit

On Tue, Mar 14, 2017 at 7:56 AM, Eric Dumazet [off-list ref] wrote:

On Tue, Mar 14, 2017 at 7:46 AM, Dmitry Vyukov [off-list ref] wrote:

quoted

I am confused. Lockdep has observed both of these stacks:

       CPU0                    CPU1
       ----                    ----
  lock(&(&q->lock)->rlock);
                               lock(_xmit_ETHER#2);
                               lock(&(&q->lock)->rlock);
  lock(_xmit_ETHER#2);


So it somehow happened. Or what do you mean?

Lockdep said " possible circular locking dependency detected " .
It is not an actual deadlock, but lockdep machinery firing.

For a dead lock to happen, this would require that he ICMP message
sent by ip_expire() is itself fragmented and reassembled.
This cannot be, because ICMP messages are not candidates for
fragmentation, but lockdep can not know that of course...

It doesn't have to be ICMP, as long as get the same hash for
the inet_frag_queue, we will need to take the same lock and
deadlock will happen.

        hash = ipqhashfn(iph->id, iph->saddr, iph->daddr, iph->protocol);

So it is really up to this hash function.