Messages in this thread | | | Date | Fri, 8 Feb 2013 13:44:17 -0800 | From | Zach Brown <> | Subject | Re: Improving AIO cancellation |
| |
> We don't know if the bio was succesfully cancelled until the bio is > completed (and this doesn't change anything about how bio completion > works) - if it was cancelled, the bi_end_io callback will get > -ECANCELLED or something.
Yeah, I think that's the right design.
> This is very different from the existing AIO cancellation; KIF_CANCEL > means "this kiocb _has been cancelled_". (sort of, I was just rereading > that code and I'm convinced it's buggy).
I don't recall the details, but the last time I looked at it I was also convinced that it was buggy.
> What we want is a new io_cancel_sane() syscall that doesn't return > anything, and only marks the iocb as "cancellation pending". The > completion would still get returned via io_getevents(), and userspace > would find out if it was cancelled or not then.
Agreed. I wonder if we can mash those semantics in to the existing call somehow. This *does* have access to the iocb, so our hands aren't as tied as we are with io_setup()'s inability to request behavioural changes.
Maybe we mark the submitted iocbs as ASYNC_BEST_EFFORT_CANCEL and then io_cancel() on them can return success and completion will proceeed as normal. Maybe much more quickly with a cancelled status but maybe not.
- z
| |