Re: io_uring: closing / release

["Stefan Bühler" <source@stbuehler.de>]

Hi,

On 23.04.19 22:31, Jens Axboe wrote:
> On 4/23/19 1:06 PM, Stefan Bühler wrote:
>> I have one other question: is there any way to cancel an IO read/write
>> operation? I don't think closing io_uring has any effect, what about
>> closing the files I'm reading/writing?  (Adding cancelation to kiocb
>> sounds like a non-trivial task; and I don't think it already supports it.)
> 
> There is no way to do that. If you look at existing aio, nobody supports
> that either. Hence io_uring doesn't export any sort of cancellation outside
> of the poll case where we can handle it internally to io_uring.
> 
> If you look at storage, then generally IO doesn't wait around in the stack,
> it's issued. Most hardware only supports queue abort like cancellation,
> which isn't useful at all.
> 
> So I don't think that will ever happen.
> 
>> So cleanup in general seems hard to me: do I have to wait for all
>> read/write operations to complete so I can safely free all buffers
>> before I close the event loop?
> 
> The ring exit waits for IO to complete already.

I now understand at least how that part is working;
io_ring_ctx_wait_and_kill calls wait_for_completion(&ctx->ctx_done),
which only completes after all references are gone; each pending job
keeps a reference.

But wait_for_completion is not interruptible; so if there are "stuck"
jobs even root can't kill the task (afaict) anymore.

Once e.g. readv is working on pipes/sockets (I have some local patches
here for that), you can easily end up in a situation where a
socketpair() or a pipe() is still alive, but the read will never finish
(I can trigger this problem with an explicit close(uring_fd), not sure
how to observe this on process exit).

For a socketpair() even both ends could be kept alive by never ending
read jobs.

Using wait_for_completion seems like a really bad idea to me; this is a
problem for io_uring_register too.

cheers,
Stefan