Re: [PATCH] aio_run_iocb should always retry

Zach Brown <[email protected]> writes:

> In any case, I don't think this is the right solution.  gadgetfs is
> pretty unusual in using one ki_retry to submit and then switching to
> another to copy the result to userspace and free.  The intent of
> ki_retry is to, well, retry.
>
> In particular, if we just fix this freeing problem by calling retry
> after cancellation then we still have the problem where a racing
> ep_aio_cancel() can try and reference freed memory if its called
> after ep_aio_read_retry() returns but before fs/aio.c takes the iocb
> out of the list.
>
> 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

This sounds reasonable to me.  It also sounds hard!  ;)

Note that there's an existing problem with failed cancellations in the
code that should be fixed (and I'm sure you'll clean it up).  Patch
attached (and soon to become irrelevant, I think).

Cheers,

Jeff

diff --git a/fs/aio.c b/fs/aio.c
index dbe699e..68eec1d 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1743,7 +1743,12 @@ asmlinkage long sys_io_cancel(aio_context_t ctx_id, struct iocb __user *iocb,
 			 */
 			if (copy_to_user(result, &tmp, sizeof(tmp)))
 				ret = -EFAULT;
-		}
+		} else
+			/* Cancellation failed -- EINVAL was returned from
+			 * sys_io_cancel and so the I/O is expected to
+			 * complete as usual.
+			 */
+			kiocbClearCancelled(kiocb);
 	} else
 		ret = -EINVAL;
 

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