public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>, [email protected]
Subject: Re: [PATCH 3/3] io_uring: move struct io_kiocb from task_struct to io_uring_task
Date: Sun, 3 Nov 2024 22:47:34 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 11/3/24 22:40, Jens Axboe wrote:
> On 11/3/24 3:36 PM, Pavel Begunkov wrote:
>> On 11/3/24 22:18, Jens Axboe wrote:
>>> On 11/3/24 3:05 PM, Pavel Begunkov wrote:
>>>> On 11/3/24 21:54, Jens Axboe wrote:
>>>>> On 11/3/24 2:47 PM, Pavel Begunkov wrote:
>>>>>> On 11/3/24 17:49, Jens Axboe wrote:
>>>>>> ...
>>>>>>> diff --git a/include/linux/io_uring/cmd.h b/include/linux/io_uring/cmd.h
>>>>>> ...
>>>>>>>          nd->head = prev_nd->head;
>>>>>>> @@ -115,7 +115,7 @@ struct io_kiocb *io_alloc_notif(struct io_ring_ctx *ctx)
>>>>>>>          notif->opcode = IORING_OP_NOP;
>>>>>>>          notif->flags = 0;
>>>>>>>          notif->file = NULL;
>>>>>>> -    notif->task = current;
>>>>>>> +    notif->tctx = current->io_uring;
>>>>>>>          io_get_task_refs(1);
>>>>>>>          notif->file_node = NULL;
>>>>>>>          notif->buf_node = NULL;
>>>>>>> diff --git a/io_uring/poll.c b/io_uring/poll.c
>>>>>>> index 7db3010b5733..56332893a4b0 100644
>>>>>>> --- a/io_uring/poll.c
>>>>>>> +++ b/io_uring/poll.c
>>>>>>> @@ -224,8 +224,7 @@ static int io_poll_check_events(struct io_kiocb *req, struct io_tw_state *ts)
>>>>>>>      {
>>>>>>>          int v;
>>>>>>>      -    /* req->task == current here, checking PF_EXITING is safe */
>>>>>>> -    if (unlikely(req->task->flags & PF_EXITING))
>>>>>>> +    if (unlikely(current->flags & PF_EXITING))
>>>>>>>              return -ECANCELED
>>>>>>
>>>>>> Unlike what the comment says, req->task doesn't have to match current,
>>>>>> in which case the new check does nothing and it'll break in many very
>>>>>> interesting ways.
>>>>>
>>>>> In which cases does it not outside of fallback?
>>>>
>>>> I think it can only be fallback path
>>>
>>> I think so too, that's what I was getting at. Hence I think we should just
>>> change these PF_EXITING checks to be PF_KTHREAD instead. If we're invoked
>>> from that kind of context, cancel.
>>
>> Replacing with just a PF_KTHREAD check won't be right, you can
>> get here with the right task but after it has been half killed and
>> marked PF_EXITING.
> 
> Right, but:
> 
> if (current->flags & (PF_EXITING | PF_KTHREAD))
> 	...
> 
> should be fine as it'll catch both cases with the single check.

Was thinking to mention it, it should be fine buf feels wrong. Instead
of directly checking what we want, i.e. whether the task we want to run
the request from is dead, we are now doing "let's check if the task
is dead. Ah yes, let's also see if it's PF_KTHREAD which indirectly
implies that the task is dead because of implementation details."

Should be fine to leave that, but why not just leave the check
how it was? Even if it now requires an extra deref through tctx.

-- 
Pavel Begunkov

  reply	other threads:[~2024-11-03 22:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-03 17:49 [PATCHSET 0/3] Move io_kiocb from task_struct to io_uring_task Jens Axboe
2024-11-03 17:49 ` [PATCH 1/3] io_uring: move cancelations to be io_uring_task based Jens Axboe
2024-11-03 17:49 ` [PATCH 2/3] io_uring: remove task ref helpers Jens Axboe
2024-11-03 17:49 ` [PATCH 3/3] io_uring: move struct io_kiocb from task_struct to io_uring_task Jens Axboe
2024-11-03 21:47   ` Pavel Begunkov
2024-11-03 21:54     ` Jens Axboe
2024-11-03 22:05       ` Pavel Begunkov
2024-11-03 22:18         ` Jens Axboe
2024-11-03 22:36           ` Pavel Begunkov
2024-11-03 22:40             ` Jens Axboe
2024-11-03 22:47               ` Pavel Begunkov [this message]
2024-11-03 22:51                 ` Jens Axboe
2024-11-03 23:17                   ` Pavel Begunkov
2024-11-03 23:25                     ` Jens Axboe
2024-11-04 15:41   ` Pavel Begunkov
2024-11-04 16:16     ` Jens Axboe
2024-11-04 16:43       ` 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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox