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 ?
/BW
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:28 EST