On 24/02/2021 12:42, Hao Xu wrote: > 在 2021/2/8 上午1:30, Pavel Begunkov 写道: >> On 06/02/2021 15:00, Xiaoguang Wang wrote: >> 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 > Hi Pavel, > I've some questions. > - Why would the resources be potentially different? My understanding is the tasks which can share a uring instance must be in the same process, so they have same context(files, mm etc.) "task" and "process" are pretty synonyms in this context, as well as struct task. And they can have different files/mm, e.g. io_uring works across fork. > - Assume 1 is true, why don't we just do something like this: > req->work.identity = req->task->io_uring->identity; > since req->task points to the original context Because there is more to be done to that, see grab_identity or something, and it may be racy to do. As mentioned, identity will cease to exist with Jens' patches, and in any case we can punt to task_work. > >> 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. > I didn't get it why here we need to import iovec. My understanding is OPs(such as readv writev) which need imoport iovec already did that in the first inline IO, what do I omit? Nope, it may skip copying them. e.g. see -EIOCBQUEUED path of io_read(). > And if it is neccessary, how do we ensure the iovec wasn't freed in userspace at the reissuing time? We should not import_iovec() for reissue after we left submit, and that's exactly the problem happening with IOPOLL. For __io_complete_rw(), Jens tells that it returns -EAGAIN IFF it called the callback from the submission, correct me if I'm wrong. I have never checked it myself, though -- Pavel Begunkov
