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. -- Jens Axboe
