public inbox for [email protected]
 help / color / mirror / Atom feed
From: Hao Xu <[email protected]>
To: io-uring <[email protected]>
Cc: Jens Axboe <[email protected]>, Pavel Begunkov <[email protected]>
Subject: Re: Possible bug for ring-mapped provided buffer
Date: Thu, 9 Jun 2022 17:33:44 +0800	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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);
  }

  reply	other threads:[~2022-06-09  9:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09  7:53 Possible bug for ring-mapped provided buffer Hao Xu
2022-06-09  9:33 ` Hao Xu [this message]
2022-06-09  9:54   ` Hao Xu
2022-06-09 10:06 ` Jens Axboe
2022-06-09 10:14   ` Hao Xu
2022-06-09 10:19     ` Jens Axboe
2022-06-09 10:32       ` Hao Xu
2022-06-09 15:06         ` Jens Axboe
2022-06-09 16:08           ` Hao Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox