lkml.org 
[lkml]   [2013]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: Question on lockdep and MAX_LOCK_DEPTH
From
Date
On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:

> It's huge, so here's a link:
>
> http://www.candelatech.com/~greearb/debug.tgz
>

The trace shows that __netif_receive_skb() is grabbing an
rcu_read_lock() but never releasing it. But I don't see any possible way
that can be true in the code.

Can you apply the following patch and run the trace again. I'd like to
see if the code is going in the path I expect it is.

Thanks,

-- Steve

diff --git a/net/core/dev.c b/net/core/dev.c
index e5942bf..5b12ff5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3260,6 +3260,7 @@ static int __netif_receive_skb(struct sk_buff *skb)
pt_prev = NULL;

rcu_read_lock();
+ trace_printk("lock\n");

another_round:
skb->skb_iif = skb->dev->ifindex;
@@ -3314,6 +3315,7 @@ ncls:
}

rx_handler = rcu_dereference(skb->dev->rx_handler);
+ trace_printk("handler %pS\n", rx_handler);
if (rx_handler) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
@@ -3359,6 +3361,7 @@ ncls:
} else {
drop:
atomic_long_inc(&skb->dev->rx_dropped);
+ trace_printk("kfree\n");
kfree_skb(skb);
/* Jamal, now you will not able to escape explaining
* me how you were going to use this. :-)
@@ -3367,6 +3370,7 @@ drop:
}

unlock:
+ trace_printk("unlock\n");
rcu_read_unlock();
out:
tsk_restore_flags(current, pflags, PF_MEMALLOC);



\
 
 \ /
  Last update: 2013-02-06 06:21    [W:0.061 / U:5.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site