Are device disconnect routines run in interrupt context?
No, khubd (or rmmod, or sometimes apmd) calls them from a task context. A disconnect() can sleep, though it should avoid doing so for very long.
What happens when a semaphore is freed from under a sleeping holder?
Bad Stuff. It's not legal. Oopses could happen ...
Basically you need to decouple some "disconnect" processingIs there a better fix that I don't see?
from the "last close". The drivers that do this right are
the ones where (a) disconnect does only a partial cleanup
when the device is still open, but (b) when that open fd is
closed, the rest of that cleanup is done.
That cleanup that's deferred till the last instant needs to
include freeing the driver's per-device memory, including
that semaphore. If I understand what you're trying to say
about that race scenario, it's that issue
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
