[lkml]   [2002]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject__skb_dequeue irq race ?
I'm trying to debug what looks like a race-condition I reach with heavy
interrupt traffic, including heavy ethernet traffic.

The result of the race (if it is one) is that the pointers in
skb_head_pool in the network code get corrupted, like the list heads
->next pointer points to the zero-page and other nasty things.

I've gotten an oops from different codepaths but one caught my eye
especially in that there seems to be a codepath with IRQ's enabled which
calls __skb_dequeue, namely do_softirq calls net_tx_action which uses
qdisc_restart which calls q->dequeue, which contains pfifo_fast_dequeue
which calls __skb_dequeue directly.

Trace; c009a508 <pfifo_fast_dequeue+22/5a>
Trace; c009a16e <qdisc_restart+16/b6>
Trace; c0094b44 <net_tx_action+7c/8c>
Trace; c0008a8c <do_softirq+4c/94>

Before diving deeper into the fray, is this normal ? If __skb_dequeue is
called with irq's enabled, couldn't another network interrupt cause a
race, corrupting the skb_head_pool linked structure ?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.075 / U:1.728 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site