On 02/10/2020 20:01, 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. I'm missing something. io_queue_async_work() calls io_prep_async_link() -> io_prep_async_work() before actually queuing. -- Pavel Begunkov
