Hello All,
I have a question about the use of the tx_ring->next_to_use variable in
the e1000. Specifically, I'm wondering about a race between the use of
next_to_use in e1000_xmit_frame and the clearing of next_to_use in
e1000_down via e1000_clean_tx_ring.
Thread 1 (_xmit) -> first = adapter->tx_ring.next_to_use;
e1000_tx_map();
Thread 2 (_down) -> e1000_clean_tx_ring();
tx_ring->next_to_use = 0;
Thread 1 (_xmit) -> e1000_tx_queue();
It seems that tx_ring.next_to_use could change between the time the skbuff
is mapped in e1000_tx_map and the time it is reported to the hardware in
e1000_tx_queue. While I don't see any memory leaks or possible oops, it
does seem possible that that an skbuff could be "lost" in the ring as it
will not be queued in the subsequent e1000_queue.
If the race is possible, perhaps this could be the culprit behind the tx
timeouts we've seen reported in this list? The watchdog will eventually
find the "lost" skbuff and mistakenly think that the hardware transmit has
hung and stop the queue.
Could one of you plese tell me how this race is avoided, if indeed it is?
Thanks,
Shaw
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
