On 11/20/2019 1:33 AM, Jens Axboe wrote:
> We currently clear the linked timeout field if we cancel such a timeout,
> but we should only attempt to cancel if it's the first one we see.
> Others should simply be freed like other requests, as they haven't
> been started yet.
>
> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>
> ---
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index a79ef43367b1..d1085e4e8ae9 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -937,12 +937,12 @@ static void io_fail_links(struct io_kiocb *req)
> if ((req->flags & REQ_F_LINK_TIMEOUT) &&
> link->submit.sqe->opcode == IORING_OP_LINK_TIMEOUT) {
> io_link_cancel_timeout(link);
> - req->flags &= ~REQ_F_LINK_TIMEOUT;
> } else {
> io_cqring_fill_event(link, -ECANCELED);
> __io_double_put_req(link);
> }
> kfree(sqe_to_free);
> + req->flags &= ~REQ_F_LINK_TIMEOUT;
That's not necessary, but maybe would safer to keep. If
REQ_F_LINK_TIMEOUT is set, than there was a link timeout request,
and for it and only for it io_link_cancel_timeout() will be called.
However, this is only true if linked timeout isn't fired. Otherwise,
there is another bug, which isn't fixed by either of the patches. We
need to clear REQ_F_LINK_TIMEOUT in io_link_timeout_fn() as well.
Let: REQ -> L_TIMEOUT1 -> L_TIMEOUT2
1. L_TIMEOUT1 fired before REQ is completed
2. io_link_timeout_fn() removes L_TIMEOUT1 from the list:
REQ|REQ_F_LINK_TIMEOUT -> L_TIMEOUT2
3. free_req(REQ) then call io_link_cancel_timeout(L_TIMEOUT2)
leaking it (as described in my patch).
P.S. haven't tried to test nor reproduce it yet.
> }
>
> io_commit_cqring(ctx);
>
--
Pavel Begunkov
