On 13/10/2020 15:57, Jens Axboe wrote: > On 10/13/20 3:46 AM, Pavel Begunkov wrote: >> On 13/10/2020 09:43, Pavel Begunkov wrote: >>> This removes REQ_F_COMP_LOCKED to fix a couple of problems with it. >>> >>> [5/5] is harsh and some work should be done to ease the aftermath, >>> i.e. io_submit_flush_completions() and maybe fail_links(). >>> >>> Another way around would be to replace the flag with an comp_locked >>> argument in put_req(), free_req() and so on, but IMHO in a long run >>> removing it should be better. >>> >>> note: there is a new io_req_task_work_add() call in [5/5]. Jens, >>> could you please verify whether passed @twa_signal_ok=true is ok, >>> because I don't really understand the difference. > > It should be fine, the only case that can't use 'true' is when it's > called from within the waitqueue handler as we can recurse on that > lock. Got it. And thanks for fixing descriptions! > > Luckily that'll all go away once the TWA_SIGNAL improvement patches > are ready. > >> btw, when I copied task_work_add(TWA_RESUME) from __io_free_req(), >> tasks were hanging sleeping uninterruptibly, and fail_links() >> wasn't waking them. It looks like the deferring branch of >> __io_free_req() is buggy as well and should use >> io_req_task_work_add(). > > Probably related to exit conditions. Yep, kind of close() -> ->flush() -> io_uring_cancel_files() -> schedule() -- Pavel Begunkov