On Sat, 29 May 2004, Oliver Neukum wrote:

> Am Samstag, 29. Mai 2004 17:23 schrieb Alan Stern:
> > However, there's a definite disadvantage to using dev->serialize for this
> > purpose: It can delay khubd and disconnect notifications.  usb-storage
> > can wait for fairly long periods, 20 or 30 seconds sometimes.  If it holds
> > the serialize semaphore during those times then it will block khubd if the
> > device is disconnected.
> 
> Why? Won't the transaction fail within the usual time?

You're right; I over-reacted.  However, there is a 6-second delay in the
device reset code (you remember, it's the call to msleep() that I asked
not to have applied).  That won't be cut short by any failed transaction.  

So to make this work, your original complaint will have to be rescinded -- 
the serialize semaphore must _not_ be held during the device reset call 
made in invoke_transport.  Actually that's okay, since the reset is an 
ep0 control request, not a regular SCSI command.

> > On the whole, it might be better to add a new mutex to struct usb_device 
> > to provide this sort of driver-level serialization rather than overload 
> > the existing mutex, which is meant to serialize actions by usbcore.
> 
> But we should guard against actions by or through usbcore, too.
> If I understand the problem correctly ep 0 must not be touched within
> this window, no matter what.

Granted that's so, it doesn't mean we need to use ->serialize.  And if we
do, the parts of usbcore that could send messages to ep0 (probably just
the usbfs and sysfs routines) will have to be changed to lock the device.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to