David Brownell wrote: > 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).
My source was LDD3, it has a section on transmission concurrency and states that netif_tx_disable is the same as netif_stop_queue but it additionally ensure that hard_start_xmit is running is not running on any CPU. That makes sense from the implementation too - it relies on taking the lock which is taken over the hard_start_xmit call. > Maybe it'd be good to ask over on netdev whether that argument shouldn't > be applied to pretty much every network driver... I will ask there. I think it probably depends on the situation, and if there is any danger of race in each case. In this case the danger is that hard_start_xmit is still running when free_netdev is called, maybe this does not apply in other cases. > 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.) That's interesting, thanks for pointing it out (helps me with my WLAN driver a little), but this race isn't related to urbs. > 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. The issue I am looking at is that usbnet_start_xmit may be running concurrently to the disconnect function. usbnet_start_xmit is not an URB completion, it's a hook into the network layer (hard_start_xmit). The issue is that usbnet_start_xmit uses structures which are freed in the disconnect function. Am I making sense? Daniel _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
