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.
Signed-off-by: Sarah Sharp <[EMAIL PROTECTED]>
Signed-off-by: Jamey Sharp <[EMAIL PROTECTED]>
---
I've been using gadgetfs (the USB slave filesystem) as an example for
how to do in-kernel AIO. Both gadgetfs and usbfs2 use callbacks from
the USB core to know when data is transfered. If the transfer was a
write, the completion function simply calls aio_complete() and frees
data structures. If it's a read, the completion function function calls
kick_iocb(). The retry function copies data into userspace, calls
aio_complete(), and then frees the data structures.
The problem comes when someone calls sys_io_cancel() on a read. If the
retry function has started before this point, everything is fine.
However, if sys_io_cancel() runs before the retry function, aio_run_iocb
will notice the iocb is cancelled and call aio_complete instead. The
retry function never runs, and the data structures are never freed.
Jamey and I believe there is no way to know in the cancel function if
the retry function will be called. Therefore, kick_iocb() should always
call the retry function. This patch fixes that bug.
I'd love to ditch the in-kernel AIO and use syslets instead, but Greg
won't accept my usbfs2 patches until I've implemented AIO, and I don't
want to keep waiting.
Sarah Sharp
fs/aio.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index dbe699e..439c0a7 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -700,14 +700,6 @@ static ssize_t aio_run_iocb(struct kiocb *iocb)
iocb->ki_run_list.next = iocb->ki_run_list.prev = NULL;
spin_unlock_irq(&ctx->ctx_lock);
- /* Quit retrying if the i/o has been cancelled */
- if (kiocbIsCancelled(iocb)) {
- ret = -EINTR;
- aio_complete(iocb, ret, 0);
- /* must not access the iocb after this */
- goto out;
- }
-
/*
* Now we are all set to call the retry method in async
* context. By setting this thread's io_wait context
--
1.4.4.1
-------------------------------------------------------------------------
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/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
