From: Pavel Begunkov <asml.silence@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, Josef <josef.grieb@gmail.com>,
io-uring@vger.kernel.org
Cc: norman@apache.org
Subject: Re: io_uring process termination/killing is not working
Date: Sat, 15 Aug 2020 10:45:36 +0300 [thread overview]
Message-ID: <bb45665c-1311-807d-5a03-459cf3cbd103@gmail.com> (raw)
In-Reply-To: <d0621b79-4277-a9ad-208e-b60153c08d15@kernel.dk>
On 13/08/2020 02:32, Jens Axboe wrote:
> On 8/12/20 12:28 PM, Pavel Begunkov wrote:
>> On 12/08/2020 21:22, Pavel Begunkov wrote:
>>> On 12/08/2020 21:20, Pavel Begunkov wrote:
>>>> On 12/08/2020 21:05, Jens Axboe wrote:
>>>>> On 8/12/20 11:58 AM, Josef wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have a weird issue on kernel 5.8.0/5.8.1, SIGINT even SIGKILL
>>>>>> doesn't work to kill this process(always state D or D+), literally I
>>>>>> have to terminate my VM because even the kernel can't kill the process
>>>>>> and no issue on 5.7.12-201, however if IOSQE_IO_LINK is not set, it
>>>>>> works
>>>>>>
>>>>>> I've attached a file to reproduce it
>>>>>> or here
>>>>>> https://gist.github.com/1Jo1/15cb3c63439d0c08e3589cfa98418b2c
>>>>>
>>>>> Thanks, I'll take a look at this. It's stuck in uninterruptible
>>>>> state, which is why you can't kill it.
>>>>
>>>> It looks like one of the hangs I've been talking about a few days ago,
>>>> an accept is inflight but can't be found by cancel_files() because it's
>>>> in a link.
>>>
>>> BTW, I described it a month ago, there were more details.
>>
>> https://lore.kernel.org/io-uring/34eb5e5a-8d37-0cae-be6c-c6ac4d85b5d4@gmail.com
>
> Yeah I think you're right. How about something like the below? That'll
> potentially cancel more than just the one we're looking for, but seems
> kind of silly to only cancel from the file table holding request and to
> the end.
The bug is not poll/t-out related, IIRC my test reproduces it with
read(pipe)->open(). See the previously sent link.
As mentioned, I'm going to patch that up, if you won't beat me on that.
>
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 8a2afd8c33c9..0630a9622baa 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -4937,6 +5003,7 @@ static bool io_poll_remove_one(struct io_kiocb *req)
> io_cqring_fill_event(req, -ECANCELED);
> io_commit_cqring(req->ctx);
> req->flags |= REQ_F_COMP_LOCKED;
> + req_set_fail_links(req);
> io_put_req(req);
> }
>
> @@ -7935,6 +8002,47 @@ static bool io_wq_files_match(struct io_wq_work *work, void *data)
> return work->files == files;
> }
>
> +static bool __io_poll_remove_link(struct io_kiocb *preq, struct io_kiocb *req)
> +{
> + struct io_kiocb *link;
> +
> + if (!(preq->flags & REQ_F_LINK_HEAD))
> + return false;
> +
> + list_for_each_entry(link, &preq->link_list, link_list) {
> + if (link != req)
> + break;
> + io_poll_remove_one(preq);
> + return true;
> + }
> +
> + return false;
> +}
> +
> +/*
> + * We're looking to cancel 'req' because it's holding on to our files, but
> + * 'req' could be a link to another request. See if it is, and cancel that
> + * parent request if so.
> + */
> +static void io_poll_remove_link(struct io_ring_ctx *ctx, struct io_kiocb *req)
> +{
> + struct hlist_node *tmp;
> + struct io_kiocb *preq;
> + int i;
> +
> + spin_lock_irq(&ctx->completion_lock);
> + for (i = 0; i < (1U << ctx->cancel_hash_bits); i++) {
> + struct hlist_head *list;
> +
> + list = &ctx->cancel_hash[i];
> + hlist_for_each_entry_safe(preq, tmp, list, hash_node) {
> + if (__io_poll_remove_link(preq, req))
> + break;
> + }
> + }
> + spin_unlock_irq(&ctx->completion_lock);
> +}
> +
> static void io_uring_cancel_files(struct io_ring_ctx *ctx,
> struct files_struct *files)
> {
> @@ -7989,6 +8097,8 @@ static void io_uring_cancel_files(struct io_ring_ctx *ctx,
> }
> } else {
> io_wq_cancel_work(ctx->io_wq, &cancel_req->work);
> + /* could be a link, check and remove if it is */
> + io_poll_remove_link(ctx, cancel_req);
> io_put_req(cancel_req);
> }
>
>
--
Pavel Begunkov
next prev parent reply other threads:[~2020-08-15 21:54 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 17:58 io_uring process termination/killing is not working Josef
2020-08-12 18:05 ` Jens Axboe
2020-08-12 18:20 ` Pavel Begunkov
2020-08-12 18:22 ` Pavel Begunkov
2020-08-12 18:28 ` Pavel Begunkov
2020-08-12 23:32 ` Jens Axboe
2020-08-13 16:07 ` Josef
2020-08-13 16:09 ` Jens Axboe
2020-08-15 7:45 ` Pavel Begunkov [this message]
2020-08-15 15:12 ` Jens Axboe
2020-08-15 16:48 ` Pavel Begunkov
2020-08-15 21:43 ` Josef
2020-08-15 22:35 ` Jens Axboe
2020-08-15 23:21 ` Josef
2020-08-15 23:31 ` Jens Axboe
2020-08-16 0:36 ` Josef
2020-08-16 0:41 ` Jens Axboe
2020-08-16 1:21 ` Jens Axboe
2020-08-16 3:14 ` Josef
2020-08-16 3:20 ` Jens Axboe
2020-08-16 17:30 ` Jens Axboe
2020-08-16 21:09 ` Josef
2020-08-16 22:17 ` Jens Axboe
2020-08-17 8:58 ` Josef
2020-08-17 10:08 ` Pavel Begunkov
2020-08-16 13:45 ` Jens Axboe
2020-08-16 14:53 ` Jens Axboe
2020-08-16 15:22 ` Jens Axboe
2020-08-17 10:16 ` Pavel Begunkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb45665c-1311-807d-5a03-459cf3cbd103@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=josef.grieb@gmail.com \
--cc=norman@apache.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.