Re: [USB-hacking] [PATCH] aio_run_iocb should always retry

> I tried to trace the O_DIRECT AIO path to figure out how AIO was
> intended to be implemented, and got hopelessly lost.

The functionality is pretty simple when viewed from far enough away  
that you don't have to see the code :).

fs/direct-io.c builds up and submits bios.  Once they're all in  
flight it returns -EIOCBQUEUED and sys_io_submit() returns.   
Eventually those bios will complete.  As each does a callback is  
called and a ref count is dropped.  When the ref count shows that all  
the ios have completed aio_complete() is called.

Look for the aio_complete() call in fs/direct-io.c and work backwards.

And bring a glass of wine.  A bottle.  Maybe a case.

> EAGAIN never seems like the right answer to me for cancel, but you
> understand this system better than I want to. :-) Shouldn't
> sys_io_cancel block until it can either successfully cancel or report
> that the iocb already completed?

Well, the presumption is that sys_io_cancel() wants to be non- 
blocking.  You can get the blocking semantics, if awkwardly, with a  
wrapper which calls sys_io_getevents() and waits for completion if  
the given iocb couldn't be cancelled.  It's not very elegant.

But historically it hasn't mattered much because people *really* want  
cancellation for ops which don't guarantee forward progress (recvmsg 
()), which fs/aio.c doesn't support.  And disk ios can't be canceled  
once they're heading down the storage stack.  So there's been  
relatively little pressure to address the giant pile of stink that  
has been the fs/aio.c cancel code.

You USB weird-os are making life hard by actually trying to *use* the  
features that fs/aio.c claims to support :).

> I don't understand why that makes it harder. Can't you pull it off  
> with
> a spinlock in the kiocb?

The difficulty comes from the imbalance between the calling  
relationships.  ki_cancel is the core calling the subsystem.   
aio_complete() is the subsystem calling the core.  If we use spin  
locks to synchronize the two then we have to be careful about not  
creating obvious hazards for lock inversions:

sys_io_cancel -> grab ctx lock -> call ki_cancel -> grab some subsys  
lock

subsys -> grab some sybsys lock -> aio_complete() -> grab ctx lock

Sure, it can all be done.  It just has to be done carefully.  I think  
it's fair to call that harder :)

- z

-------------------------------------------------------------------------
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