On 29/02/2020 02:37, Pavel Begunkov wrote: > After io_put_req_find_next() was patched, handlers no more return > next work, but enqueue them through io_queue_async_work() (mostly > by io_put_work() -> io_put_req()). The patchset fixes that. > > Patches 1-2 clean up and removes all futile attempts to get nxt from > the opcode handlers. The 3rd one moves all this propagation idea into > work->put_work(). And the rest ones are small clean up on top. And now I'm hesitant about the approach. It works fine, but I want to remove a lot of excessive locking from io-wq, and it'll be in the way. Ignore this, I'll try something else The question is whether there was a problem with io_req_find_next() in the first place... It was stealing @nxt, when it already completed a request and were synchronous to the submission ref holder, thus it should have been fine. > v2: rebase on top of poll changes > > Pavel Begunkov (5): > io_uring: remove @nxt from the handlers > io_uring/io-wq: pass *work instead of **workptr > io_uring/io-wq: allow put_work return next work > io_uring: remove extra nxt check after punt > io_uring: remove io_prep_next_work() > > fs/io-wq.c | 28 ++--- > fs/io-wq.h | 4 +- > fs/io_uring.c | 320 ++++++++++++++++++++------------------------------ > 3 files changed, 141 insertions(+), 211 deletions(-) > -- Pavel Begunkov
