On Thursday 08 June 2006 12:18 pm, Daniel Drake wrote: > However, netif_stop_queue() may return with transmissions still running > on other CPUs - I think netif_tx_disable() is what is needed, which > guarantees that no transmissions are active when it returns. > > Do you agree that this is a potential race?
Hmm, most drivers call netif_stop_queue() rather than netif_tx_disable(); a quick conversation with Mr. Grep shows only three uses of the latter. And with no documentation, it's a bit hard for me to agree (without diving deeper into the network stack than I have time for). Maybe it'd be good to ask over on netdev whether that argument shouldn't be applied to pretty much every network driver... That said, I don't see an obvious race there. If the device disconnects, there's now a guarantee that all pending urbs will have completed before the driver disconnect() method is called. (As of maybe 2.6.8 or so. The original 2.4 code of course couldn't rely on such guarantees. The lack of such guarantees meant a seemingly endless supply of oops-on-disconnect bugs.) So there is no way that an URB completion can trigger with an invalid device handle, which is I think the race you implied. Even if one CPU were able to submit an URB after the TX queue stopped, there'd be no trouble. - Dave _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
