Re: [PATCH] aio_run_iocb should always retry
Zach Brown <[email protected]>
| Newsgroups | gmane.linux.usb.devel,gmane.linux.kernel.aio.general |
|---|---|
| Message-ID | <[email protected]> |
> What are you talking about? There's only one retry function!! The initial operation submission is implemented by building an iocb in the run_list and calling its ki_retry before returning to userspace. The terminology of referring to that initial submission as ki_retry is confusing to the vast majority who don't have scars from fs/aio.c. Sorry :). > That one won't work. The reason for cancelation will normally be > that the I/O has blocked -- so retry() will *never* be called! This is an instance of me confusing you with my sloppy fs/aio.c terminology. In this case, "ki_retry" meant "the aio_ f_op method because it's called from a wrapper acting as ki_retry for the initial submission.". > Plus, when returning after zero byte I/O (protocol-significant in > USB), > retry() may never be called... (more confusion) > It should probably be OK to call ki_cancel() at any point before > aio_complete() is called, after the kiocb is activated. If it's > called outside of that window, the answer should be deterministic. Yup, it will be. > Re releasing resources, I'd think that whoever allocates them should > free them... possibly there should be a hook to delegate that stuff. > So for example, such a hook in gadgetfs could release the usb_request > and its associated buffer. Perhaps, but I'm not sure we need to address that in the set of patches which fix the worst behaviour of cancellation. If we give _cancel, _retry, and aio_ ops easy rules to discover their last chance to free that might be enough. A hook to free can be complicated as the final iocb ref can be dropped in interrupt handlers and the most naive implementation will want to be called holding locks. Hooks that can be called with interrupts masked and locks held are not particularly friendly. - 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