On Thu, 24 Oct 2002, Oliver Neukum wrote:
> Hi,
>
> > The point I was raising is that once khubd starts its cleanup, only
> > one activity makes sense: unlinking urbs. But today, it's _also_
>
> Correct, so we want the core to do that, don't we?
>
> > possible to continue submitting urbs. That can create some exotic
> > failure modes, worth IMO getting rid of -- I've seen drivers cause
> > them, they're a waste of time to debug rather than just prevent.
>
> Definitely, if we can find a way to do so.
>
> > Think of it as a proof-by-induction that shutdown will work. When
> > there's a point past which no more activities can be started (like
> > when device state becomes GONE), and existing activities all get
> > canceled, shutdown will clearly work. With no such point, the exotic
> > failure modes can prevent shutdown from working.
>
> Correct, but incomplete.
> You see, the full transition on unplugging is twofold from
> WORKING to GONE to <NONE AT ALL>. The last state is caused
> by kfree on the device descriptor. Preventing submission in the second
> state is no problem. That's not the case for the last state unfortunately.
>
> Regards
> Oliver
Hear, hear!
It seems clear that the best way for the core to handle this situation is:
Keep track of all active URBs on a per-device list.
When a device unplugs from the bus, set the device state
to GONE and cancel (with some appropriate error code like
-ENODEV, which already means the device was removed) all
active URBs. Then call the drivers' disconnect() routines.
When the device is GONE, fail (with -ENODEV) all calls to
usb_submit_urb.
Rely on the driver not to submit any more URBs once
disconnect() has returned. If the device structure happens
to hang around in memory for a while, you can log an error
message (or even oops) on any submissions for a removed device.
This centralizes the functionality in the core to the largest reasonable
extent. The onus on the drivers is minimized; every driver should be able
to avoid submitting URBs for devices that they already know are gone.
Alan Stern
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
