On 7/10/21 8:07 AM, Pavel Begunkov wrote: > On 7/10/21 2:40 PM, Jens Axboe wrote: >> On Fri, Jul 9, 2021 at 7:46 PM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote: >>> When we use delayed_work for fallback execution of requests, current >>> will be not of the submitter task, and so checks in io_req_task_submit() >>> may not behave as expected. Currently, it leaves inline completions not >>> flushed, so making io_ring_exit_work() to hang. Use the submitter task >>> for all those checks. >>> >>> Cc: stable@xxxxxxxxxxxxxxx >>> Signed-off-by: Pavel Begunkov <asml.silence@xxxxxxxxx> >>> --- >>> fs/io_uring.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/fs/io_uring.c b/fs/io_uring.c >>> index 7167c61c6d1b..770fdcd7d3e4 100644 >>> --- a/fs/io_uring.c >>> +++ b/fs/io_uring.c >>> @@ -2016,7 +2016,7 @@ static void io_req_task_submit(struct io_kiocb *req) >>> >>> /* ctx stays valid until unlock, even if we drop all ours ctx->refs */ >>> mutex_lock(&ctx->uring_lock); >>> - if (!(current->flags & PF_EXITING) && !current->in_execve) >>> + if (!(req->task->flags & PF_EXITING) && !req->task->in_execve) >>> __io_queue_sqe(req); >>> else >>> io_req_complete_failed(req, -EFAULT); >> >> I don't think that ->in_execve check is useful anymore now that we don't >> have weak references to the files table, so it should probably just go >> away. > > Had such a thought but from the premise that on exec we wait / cancel > all requests. But I'd rather to leave it to a separate commit for-next, > don't you think so? Yes, probably best left for for-next. I'll apply this one as-is, thanks. -- Jens Axboe
