Re: [RFC] usbfs2 aio cancellation code

Alan Stern <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
On Mon, 1 Oct 2007, Sarah Bailey wrote:

> I've been trying to figure out how usbfs2's code would look with the new
> in-kernel aio cancellation and serialization rules. [1]  It's making my
> head hurt, so I'd appreciate some code review.
> 
> Background:
> 
> The in-kernel aio patches that Zack is working will ensure that the
> retry function and the cancel function will run serially.  If the cancel
> function returns 0, the iocb will be destroyed.  If cancel returns zero,
> it guarantees that the iocb will never be referenced again, specifically
> by making sure that kick_iocb() and aio_complete() have never been and
> never will be called.
> 
> Some USB rules apply here too.  To cancel a USB transaction, you can
> call either usb_kill_urb() or usb_unlink_urb().  usb_kill_urb() will
> wait for the URB callback to complete, but it cannot be called with a
> spin lock held.  usb_unlink_urb() guarantees that the URB callback will
> be called sometime in the future with an URB status that indicates it
> was cancelled.  usb_unlink_urb() will return -EBUSY if the URB callback
> was about to run or was in the middle of running.

Do things really need to be this complicated?

It ought to be simpler to use an atomic bitflag to indicate that the
URB has completed or been cancelled.  In both the aio_cancel routine
and the URB completion handler you call test_and_set_bit().  If the bit
was already set then there's nothing to do; fail the cancellation or
ignore the URB completion.  If the bit wasn't set then unlink the URB
and cancel the aio operation, or go ahead and complete the aio
operation.

How does the aio core handle the unavoidable race between cancellation 
and completion?

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.