From: Jens Axboe <axboe@kernel.dk>
To: Pavel Begunkov <asml.silence@gmail.com>, io-uring@vger.kernel.org
Subject: Re: [PATCH 1/5] io_uring: grab any needed state during defer prep
Date: Fri, 2 Oct 2020 11:09:34 -0600 [thread overview]
Message-ID: <d389c8bc-8257-cafa-6f85-7dc82d22773f@kernel.dk> (raw)
In-Reply-To: <f95eb757-795a-adcc-e4ea-e0a783d62a29@kernel.dk>
On 10/2/20 11:01 AM, Jens Axboe wrote:
> On 10/2/20 10:34 AM, Pavel Begunkov wrote:
>> On 02/10/2020 19:14, Pavel Begunkov wrote:
>>> On 19/09/2020 19:56, Pavel Begunkov wrote:
>>>> On 19/09/2020 18:27, Pavel Begunkov wrote:
>>>>> On 14/09/2020 19:25, Jens Axboe wrote:
>>>>>> Always grab work environment for deferred links. The assumption that we
>>>>>> will be running it always from the task in question is false, as exiting
>>>>>> tasks may mean that we're deferring this one to a thread helper. And at
>>>>>> that point it's too late to grab the work environment.
>>>> Forgot that they will be cancelled there. So, how it could happen?
>>>> Is that the initial thread will run task_work but loosing
>>>> some resources like mm prior to that? e.g. in do_exit()
>>>
>>> Jens, please let me know when you get time for that. I was thinking that
>>> you were meaning do_exit(), which does task_work_run() after killing mm,
>>> etc., but you mentioned a thread helper in the description... Which one
>>> do you mean?
>>
>> Either it refers to stuff after io_ring_ctx_wait_and_kill(), which
>> delegates the rest to io_ring_exit_work() via @system_unbound_wq.
>
> We punt the request to task_work. task_work is run, we're still in the
> right context. We fail with -EAGAIN, and then call io_queue_async_work()
> and we're not doing async prep at that point.
BTW, I think we can improve on this for 5.10, on top of your cleanups.
So that would certainly be welcome!
--
Jens Axboe
next prev parent reply other threads:[~2020-10-02 17:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 16:25 [PATCHSET 0/5] io_uring fixes for 5.9 Jens Axboe
2020-09-14 16:25 ` [PATCH 1/5] io_uring: grab any needed state during defer prep Jens Axboe
2020-09-19 15:27 ` Pavel Begunkov
2020-09-19 16:56 ` Pavel Begunkov
2020-10-02 16:14 ` Pavel Begunkov
2020-10-02 16:34 ` Pavel Begunkov
2020-10-02 17:01 ` Jens Axboe
2020-10-02 17:08 ` Pavel Begunkov
2020-10-02 17:09 ` Jens Axboe [this message]
2020-10-02 17:14 ` Pavel Begunkov
2020-09-14 16:25 ` [PATCH 2/5] io_uring: drop 'ctx' ref on task work cancelation Jens Axboe
2020-09-14 16:25 ` [PATCH 3/5] io_uring: don't run task work on an exiting task Jens Axboe
2020-09-14 16:25 ` [PATCH 4/5] io_uring: don't re-setup vecs/iter in io_resumit_prep() is already there Jens Axboe
2020-09-14 16:25 ` [PATCH 5/5] io_uring: don't use retry based buffered reads for non-async bdev Jens Axboe
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=d389c8bc-8257-cafa-6f85-7dc82d22773f@kernel.dk \
--to=axboe@kernel.dk \
--cc=asml.silence@gmail.com \
--cc=io-uring@vger.kernel.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.