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);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
