Hi, On 27.04.19 23:07, Stefan Bühler wrote: > 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. As far as I know this is not a problem yet in 5.1 as reads on pipes and sockets are still blocking the submission, and SQPOLL is only for CAP_SYS_ADMIN. But once my "punt to workers if file doesn't support async" patch (or something similar) goes in, this will become a real problem. My current trigger looks like this: create socketpair(), submit read from both ends (using the same iovec... who cares), wait for the workers to pick up the reads, munmap everything and exit. The kernel will then cleanup the files: but the sockets are still in use by io_uring, and it will only close the io_uring context, which will then get stuck in io_ring_ctx_wait_and_kill. In my qemu test environment "nobody" can leak 16 contexts before hitting some resource limits. cheers, Stefan
