On 06/02/2020 23:58, Jens Axboe wrote: >> >> 1. submit a read, which need defer. >> >> 2. io_req_defer() allocates ->io and goes io_req_defer_prep() -> io_read_prep(). >> Let #vecs > UIO_FASTIOV, so the prep() in the presence of ->io will allocate iovec. >> Note: that work.func is left io_wq_submit_work >> >> 3. At some point @io_wq calls io_wq_submit_work() -> io_issue_sqe() -> io_read(), >> >> 4. actual reading succeeds, and it's coming to finalisation and the following >> code in particular. >> >> if (!io_wq_current_is_worker()) >> kfree(iovec); >> >> 5. Because we're in io_wq, the cleanup will not be performed, even though we're >> returning with success. And that's a leak. >> >> Do you see anything wrong with it? > > That's my bad, I didn't read the subject fully, this is specific to > a deferred request. Patch looks good to me, and it cleans it up too > which is always a nice win! > Great we're agree. Though, it's not only about defer, it's just one example. The another one is a non-head request, for which io_submit_sqe() allocates ->io, + REQ_F_FORCE_ASYNC. -- Pavel Begunkov
Attachment:
signature.asc
Description: OpenPGP digital signature
