On 02/10/2020 20:09, Jens Axboe wrote: > 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! Yeah, I was going for that, it'll be in my way anyway. -- Pavel Begunkov
