David Brownell wrote:
> So to summarize all that discussion ... no disconnect race in usbnet.
> Right?
Yep, unregister_netdev ensures that the case I suggested does not happen.
Daniel
___
[email protected]
To unsubscribe, use the
So to summarize all that discussion ... no disconnect race in usbnet.
Right?
- Dave
___
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Am Donnerstag, 8. Juni 2006 23:55 schrieb David Brownell:
> Maybe it'd be good to ask over on netdev whether that argument shouldn't
> be applied to pretty much every network driver...
Yes
> That said, I don't see an obvious race there. If the device disconnects,
> there's now a guarantee that
On Thu, 8 Jun 2006, David Brownell wrote:
> On Thursday 08 June 2006 8:26 pm, Alan Stern wrote:
> > On Thu, 8 Jun 2006, David Brownell wrote:
> >
> > > 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
On Thursday 08 June 2006 8:26 pm, Alan Stern wrote:
> On Thu, 8 Jun 2006, David Brownell wrote:
>
> > 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.
On Thu, 8 Jun 2006, David Brownell wrote:
> 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
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 f
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
Hi David,
I'm currently working on fixing possible disconnect races in a USB-WLAN
driver, and to start with I'm trying to convince myself that such races
don't exist in other USB networking drivers (and why).
I had a quick look at usbnet, and decided that one such possible race
could occur i