> > Though this does raise the issue that it probably makes sense to
> > have the "hardware" layer suspended while the upper layers'
> > "virtual devices" don't know about it.  That's not the assumption
> > I think we've been using so far...
> 
> No, and I won't be surprised if it comes back later to bite us!

Storage is special because SCSI hides open/close.
 
[..]
> You're correct that resume will fail-fast.  But down(&udev->serialize)  
> won't!  That's where the blockage is: inside locktree -- the task is
> waiting to lock the device.  Once the device has been locked and the 
> resume code gets a chance to execute it will indeed fail quickly.
> 
> Diagrammatically:
> 
>       usb-storage control thread      khubd
>       --------------------------      -----
>       dequeue next SCSI command
>       start to perform the command,
>         but the device has been
>         suspended
>                                       lock the parent hub
>                                       get port connect change event
>                                       call usb_disconnect
>                                       lock the device
>       call usb_resume_device
>       call locktree: Blocks trying
>         to lock the parent hub
>                                       call usb_storage:disconnect()
>                                       wait for control thread to exit:
>                                         Deadlock!
> 
> Testing for udev->state != USB_STATE_NOTATTACHED prior to doing the down()  
> will help but won't completely eliminate the window.  I'm beginning to
> think that locktree() needs to fail without blocking indefinitely if the
> device is marked NOTATTACHED.

That would result in a monstrously complex thing with timeouts.
I'd suggest to reduce complexity and move to a global rwsem for now.
If there's contention we can care about it later.

Independent from that, you might use a workqueue triggered by
queuecommand() itself.

> The other possibility is for the usb_storage disconnect routine to exit 
> _without_ waiting for the control thread to finish.  Until module unload 
> support is improved, that will almost certainly lead to oopses.

Eek. Don't do that.

        Regards
                Oliver


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to