Re: Possible bug for ring-mapped provided buffer

[Hao Xu <hao.xu@linux.dev>]

On 6/9/22 15:53, Hao Xu wrote:
> Hi all,
> I haven't done tests to demonstrate it. It is for partial io case, we
> don't consume/release the buffer before arm_poll in ring-mapped mode.
> But seems we should? Otherwise ring head isn't moved and other requests
> may take that buffer. What do I miss?
> 
> Regards,
> Hao

something like this:


diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
index d2b2b4728381..ae4c69ad0f86 100644
--- a/io_uring/kbuf.c
+++ b/io_uring/kbuf.c
@@ -48,7 +48,10 @@ void __io_kbuf_recycle(struct io_kiocb *req, unsigned 
issue_flags)
          * If the tail has already been incremented, hang on to it.
          */
         if (req->flags & REQ_F_BUFFER_RING) {
-               if (req->buf_list) {
+               if (req->flags & REQ_F_PARTIAL_IO) {
+                       req->buf_list->head++;
+                       req->buf_list = NULL;
+               } else if (req->buf_list) {
                         req->buf_index = req->buf_list->bgid;
                         req->flags &= ~REQ_F_BUFFER_RING;
                 }
diff --git a/io_uring/kbuf.h b/io_uring/kbuf.h
index b58d9d20c97e..9ecb175e60a9 100644
--- a/io_uring/kbuf.h
+++ b/io_uring/kbuf.h
@@ -58,8 +58,14 @@ static inline void io_kbuf_recycle(struct io_kiocb 
*req, unsigned issue_flags)
  {
         if (!(req->flags & (REQ_F_BUFFER_SELECTED|REQ_F_BUFFER_RING)))
                 return;
-       /* don't recycle if we already did IO to this buffer */
-       if (req->flags & REQ_F_PARTIAL_IO)
+       /*
+        * For legacy provided buffer mode, don't recycle if we already did
+        * IO to this buffer. For ring-mapped provided buffer mode, we 
should
+        * increment ring->head to explicitly monopolize the buffer to avoid
+        * multiple use.
+        */
+       if ((req->flags & REQ_F_BUFFER_SELECTED) &&
+           (req->flags & REQ_F_PARTIAL_IO))
                 return;
         __io_kbuf_recycle(req, issue_flags);
  }