On Wed, 2013-01-23 at 16:13 -0800, Ben Greear wrote: > On 01/23/2013 04:01 PM, Eric Dumazet wrote: > > On Wed, 2013-01-23 at 15:55 -0800, Ben Greear wrote: > >> On 01/22/2013 06:32 PM, Ben Greear wrote: > >> > >> So, I'm slowly making some progress. I've verified that the skb > >> has bogus dst (0xdeadbeef) at the top of the ip_rcv_finish > >> method. I'm trying to track it backwards and figure out which > >> device it belongs to, etc....takes a while to reproduce though. > >> > >> One thing about this stack trace below...the dev_seq_stop() does > >> a rcu read-unlock. Now, I can't figure out exactly how ip_rcv() > >> can cause dev_seq_stop() to run, but if this stack is legit, > >> then maybe by the time we enter the ip_rcv_finish() code we are > >> running without rcu_readlock() held? > >> > >> If so, that would probably explain the bug. > >> > > > > The whole thing is run under rcu_read_lock() done in > > __netif_receive_skb() > > I was worried that the dev_seq_stop might be called > incorrectly causing an asymetric unlock. I have no > idea how that might happened, but several crashes > have that dev_seq_stop method listed, so it got me suspicious. dev_seq_stop() is some word in the kernel stack, result of a prior system call. Stack is not cleanup. Each function reserves an amount of stack but not always write on all reserved space (some automatic variables might be not set) Note the "? " before the name : linux printed the symbol but this was not a call site for this particular call graph. Its only an extra indication, that can be useful sometimes. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
