On 08/02/2021 02:50, Xiaoguang Wang wrote: >>> The io_identity's count is underflowed. It's because in io_put_identity, >>> first argument tctx comes from req->task->io_uring, the second argument >>> comes from the task context that calls io_req_init_async, so the compare >>> in io_put_identity maybe meaningless. See below case: >>> task context A issue one polled req, then req->task = A. >>> task context B do iopoll, above req returns with EAGAIN error. >>> task context B re-issue req, call io_queue_async_work for req. >>> req->task->io_uring will set to task context B's identity, or cow new one. >>> then for above case, in io_put_identity(), the compare is meaningless. >>> >>> IIUC, req->task should indicates the initial task context that issues req, >>> then if it gets EAGAIN error, we'll call io_prep_async_work() in req->task >>> context, but iopoll reqs seems special, they maybe issued successfully and >>> got re-issued in other task context because of EAGAIN error. >> >> Looks as you say, but the patch doesn't solve the issue completely. >> 1. We must not do io_queue_async_work() under a different task context, >> because of it potentially uses a different set of resources. So, I just >> thought that it would be better to punt it to the right task context >> via task_work. But... >> >> 2. ...iovec import from io_resubmit_prep() might happen after submit ends, >> i.e. when iovec was freed in userspace. And that's not great at all. > Yes, agree, that's why I say we neeed to re-consider the io identity codes > more in commit message :) I'll have a try to prepare a better one. I'd vote for dragging -AGAIN'ed reqs that don't need io_import_iovec() through task_work for resubmission, and fail everything else. Not great, but imho better than always setting async_data. -- Pavel Begunkov
