Re: [PATCH] aio_run_iocb should always retry

On Mon, Sep 24, 2007 at 04:38:01PM -0700, Zach Brown wrote:
> 
> On Sep 21, 2007, at 3:06 PM, Sarah Sharp wrote:
> 
> >When an AIO operation is cancelled, the ki_cancel callback can't
> >determine whether the ki_retry callback will ever be called. As a
> >result, it can't correctly determine whether to free resources. This
> >patch changes aio_run_iocb to always call ki_retry.
> 
> Thanks for sending this out.  I spent a few hours staring at the  
> cancelation code in fs/aio.c.  I think I have a handle on the sorts  
> of things we'll have to address in fs/aio.c to robustly support  
> cancellation.

Thanks for looking at this; I know it's a pain.

> No, I think we should step back and fix the fundamental serialization  
> problems with sys_io_cancel().  Right now it requires each ki_cancel  
> implementation to take on way too much complexity.  How about we make  
> the following rules:
> 
> - ki_cancel will not be called while ki_retry is being called
> 
> - ki_cancel will not be called after ki_retry returns codes which  
> complete the iocb
> 
> - ki_cancel will not be called until ki_retry has returned at least once
> 
> - ki_cancel after kick_iocb() will not stop ki_retry from being called
> 
> - ki_cancel will not be called after aio_complete() has been called
> 
> The intention is to only call ki_cancel when we're in that giant idle  
> time after when ki_retry has returned either EIOCBQUEUED or  
> EIOCBRETRY but before either aio_complete() or kick_iocb() have been  
> called.  In the cases where sys_io_cancel() finds that it shouldn't  
> call ki_cancel it could return EAGAIN.
> 
> Serializing ki_retry and ki_cancel calls will be easy because they're  
> called from process context from fs/aio.c.  Serializing with  
> aio_complete() will be harder as its called from interrupts from  
> subsystems.  We might just add a call to let subsystem aio_complete()  
> callers or ki_cancel implementations negotiate who should free  
> resources.  Or leave that serialization up to the subsystems.  I'm  
> not sure.
> 
> If this sounds OK I could roll some patches.  Please tell me that you  
> guys have some tests which are failing with the current code so we  
> can verify our work.

Sounds like a plan.  Unfortunately, I don't have test cases; Jamey and I
were inspecting the aio core and noticed the bug.  I'll try to get you
some simple test cases this weekend.

Sarah

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG+s5ORqNbFWK10kwRAnkOAJ4mVrOFy+z0tcOg/Jj5hCIsO62SKQCfbxcb
ErXPKp1txBfdBirPEui3ggg=
=NSuX
-----END PGP SIGNATURE-----