Re: [RFC] usbfs2 aio cancellation code

Sarah, your name seems to mutate a lot!  Sarah Sharp vs. Sarah Bailey 
vs. saharabeara...  :-)

On Tue, 2 Oct 2007, Sarah Sharp wrote:

> > > What happens if you call usb_unlink_urb() after the URB callback has  
> > > been called?
> > 
> > Then usb_unlink_urb() fails.  But it might not return -EBUSY; it might
> > return some other error code instead.
> 
> Hmm, I thought I'd traced it correctly...  usb_unlink_urb in core/usb.c
> calls usb_hcd_unlink_urb in core/hcd.c, which returns -EBUSY if the URB
> status is anything but -EINPROGRESS.

That code path will change in 2.6.24, and as a result -EIDRM will be 
the code indicating the URB has completed or is about to complete.  
-EBUSY will mean the URB hasn't completed yet but has already been 
unlinked.  It's not very safe to rely on the meaning of any particular 
error code because they aren't documented and so are subject to change.

>  (Assuming the URB still exists and
> none of the other checks are triggered.)  Did I just misread it, or will
> something further up the stack mess with the return value?

No, you're basically correct.  My point was that the URB might not
still exist or one of those other checks might indeed be triggered.

> > > I'm hoping that we can *just* call usb_unlink_urb() from ki_cancel  
> > > and *always* return -EBUSY.  The URB callback will either be called  
> > > very soon on error or will already be in flight or have been called.
> > 
> > Right, there's no point in having ki_cancel ever complete an aio 
> > operation.  The operation should complete when the URB completes, 
> > whether it succeeded, was unlinked, or encountered some other error.
> 
> So then there's no point in using usb_kill_urb() in the cancel function,
> correct?  The cancellation function doesn't care about waiting for the
> URB callback to run, it just cares that it queued up the request for it
> to be canceled.

Correct.  usb_unlink_urb() will do exactly what you want.

> > > URB callback:
> > > 	/* usb_unlink_urb() protects the race with ki_cancel */
> > > 	/* this cannot race with ki_retry, it triggers it */
> > > 	if (read)
> > > 		kick_iocb();
> > > 	else
> > > 		aio_complete();
> 
> Do we want to test for cancel in the callback function?  It seems
> pointless to call with the kick_iocb() when there's no data to copy.

That's a good idea, an extra little optimization.  But don't forget
that a transfer can be partially successful.  If some but not all of
the data was received before an error or cancellation, you probably
will want to copy whatever you did receive.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel