On 6/15/22 11:18, Pavel Begunkov wrote:
On 6/15/22 09:20, Hao Xu wrote:
On 6/14/22 22:37, Pavel Begunkov wrote:
REQ_F_COMPLETE_INLINE is only needed to delay queueing into the
completion list to io_queue_sqe() as __io_req_complete() is inlined and
we don't want to bloat the kernel.
As now we complete in a more centralised fashion in io_issue_sqe() we
can get rid of the flag and queue to the list directly.
Signed-off-by: Pavel Begunkov <asml.silence@xxxxxxxxx>
---
io_uring/io_uring.c | 20 ++++++++------------
io_uring/io_uring.h | 5 -----
io_uring/io_uring_types.h | 3 ---
3 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 1fb93fdcfbab..fcee58c6c35e 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -1278,17 +1278,14 @@ static void io_req_complete_post32(struct io_kiocb *req, u64 extra1, u64 extra2)
inline void __io_req_complete(struct io_kiocb *req, unsigned issue_flags)
{
- if (issue_flags & IO_URING_F_COMPLETE_DEFER)
- io_req_complete_state(req);
- else
- io_req_complete_post(req);
+ io_req_complete_post(req);
}
io_read/write and provide_buffers/remove_buffers are still using
io_req_complete() in their own function. By removing the
IO_URING_F_COMPLETE_DEFER branch they will end in complete_post path
100% which we shouldn't.
Old provided buffers are such a useful feature that Jens adds
a new ring-based version of it, so I couldn't care less about
those two.
I any case, let's leave it to follow ups. Those locking is a
weird construct and shouldn't be done this ad-hook way, it's
a potential bug nest
Ok, missed io_read/write part, that's a problem, agree
--
Pavel Begunkov
