From: Uday Shankar <ushankar@purestorage.com>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/4] ublk: mark ublk_queue as const for ublk_commit_and_fetch
Date: Wed, 16 Apr 2025 13:27:30 -0600 [thread overview]
Message-ID: <aAAEoifl5tAocAYq@dev-ushankar.dev.purestorage.com> (raw)
In-Reply-To: <CADUfDZpkDUE8heSFEhA1aCfn3a59D1+=2piWPtRvX3t9FLgjbw@mail.gmail.com>
On Wed, Apr 16, 2025 at 11:59:25AM -0700, Caleb Sander Mateos wrote:
> On Tue, Apr 15, 2025 at 6:00 PM Uday Shankar <ushankar@purestorage.com> wrote:
> >
> > We now allow multiple tasks to operate on I/Os belonging to the same
> > queue concurrently. This means that any writes to ublk_queue in the I/O
> > path are potential sources of data races. Try to prevent these by
> > marking ublk_queue pointers as const when handling COMMIT_AND_FETCH.
> > Move the logic for this command into its own function
> > ublk_commit_and_fetch. Also open code ublk_commit_completion in
> > ublk_commit_and_fetch to reduce the number of parameters/avoid a
> > redundant lookup.
> >
> > Suggested-by: Ming Lei <ming.lei@redhat.com>
> > Signed-off-by: Uday Shankar <ushankar@purestorage.com>
> > ---
> > drivers/block/ublk_drv.c | 91 +++++++++++++++++++++++-------------------------
> > 1 file changed, 43 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> > index 9a0d2547512fc8119460739230599d48d2c2a306..153f67d92248ad45bddd2437b1306bb23df7d1ae 100644
> > --- a/drivers/block/ublk_drv.c
> > +++ b/drivers/block/ublk_drv.c
> > @@ -1518,30 +1518,6 @@ static int ublk_ch_mmap(struct file *filp, struct vm_area_struct *vma)
> > return remap_pfn_range(vma, vma->vm_start, pfn, sz, vma->vm_page_prot);
> > }
> >
> > -static void ublk_commit_completion(struct ublk_device *ub,
> > - const struct ublksrv_io_cmd *ub_cmd)
> > -{
> > - u32 qid = ub_cmd->q_id, tag = ub_cmd->tag;
> > - struct ublk_queue *ubq = ublk_get_queue(ub, qid);
> > - struct ublk_io *io = &ubq->ios[tag];
> > - struct request *req;
> > -
> > - /* now this cmd slot is owned by nbd driver */
> > - io->flags &= ~UBLK_IO_FLAG_OWNED_BY_SRV;
> > - io->res = ub_cmd->result;
> > -
> > - /* find the io request and complete */
> > - req = blk_mq_tag_to_rq(ub->tag_set.tags[qid], tag);
> > - if (WARN_ON_ONCE(unlikely(!req)))
> > - return;
> > -
> > - if (req_op(req) == REQ_OP_ZONE_APPEND)
> > - req->__sector = ub_cmd->zone_append_lba;
> > -
> > - if (likely(!blk_should_fake_timeout(req->q)))
> > - ublk_put_req_ref(ubq, req);
> > -}
> > -
> > /*
> > * Called from io task context via cancel fn, meantime quiesce ublk
> > * blk-mq queue, so we are called exclusively with blk-mq and io task
> > @@ -1918,6 +1894,45 @@ static int ublk_unregister_io_buf(struct io_uring_cmd *cmd,
> > return io_buffer_unregister_bvec(cmd, index, issue_flags);
> > }
> >
> > +static int ublk_commit_and_fetch(const struct ublk_queue *ubq,
> > + struct ublk_io *io, struct io_uring_cmd *cmd,
> > + const struct ublksrv_io_cmd *ub_cmd,
> > + struct request *req)
> > +{
> > + if (!(io->flags & UBLK_IO_FLAG_OWNED_BY_SRV))
> > + return -EINVAL;
> > +
> > + if (ublk_need_map_io(ubq)) {
> > + /*
> > + * COMMIT_AND_FETCH_REQ has to provide IO buffer if
> > + * NEED GET DATA is not enabled or it is Read IO.
> > + */
> > + if (!ub_cmd->addr && (!ublk_need_get_data(ubq) ||
> > + req_op(req) == REQ_OP_READ))
> > + return -EINVAL;
> > + } else if (req_op(req) != REQ_OP_ZONE_APPEND && ub_cmd->addr) {
> > + /*
> > + * User copy requires addr to be unset when command is
> > + * not zone append
> > + */
> > + return -EINVAL;
> > + }
> > +
> > + ublk_fill_io_cmd(io, cmd, ub_cmd->addr);
> > +
> > + /* now this cmd slot is owned by ublk driver */
> > + io->flags &= ~UBLK_IO_FLAG_OWNED_BY_SRV;
> > + io->res = ub_cmd->result;
> > +
> > + if (req_op(req) == REQ_OP_ZONE_APPEND)
> > + req->__sector = ub_cmd->zone_append_lba;
> > +
> > + if (likely(!blk_should_fake_timeout(req->q)))
> > + ublk_put_req_ref(ubq, req);
> > +
> > + return -EIOCBQUEUED;
>
> I think it would be clearer to just return 0. __ublk_ch_uring_cmd()
> already takes care of returning -EIOCBQUEUED in the successful case.
Sounds good - your recommendation is also in line with the convention
Ming is using in
https://lore.kernel.org/linux-block/20250416035444.99569-2-ming.lei@redhat.com/
next prev parent reply other threads:[~2025-04-16 19:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 0:59 [PATCH v4 0/4] ublk: decouple server threads from hctxs Uday Shankar
2025-04-16 0:59 ` [PATCH v4 1/4] ublk: require unique task per io instead of unique task per hctx Uday Shankar
2025-04-16 18:48 ` Caleb Sander Mateos
2025-04-16 19:26 ` Uday Shankar
2025-04-16 0:59 ` [PATCH v4 2/4] ublk: mark ublk_queue as const for ublk_commit_and_fetch Uday Shankar
2025-04-16 18:59 ` Caleb Sander Mateos
2025-04-16 19:27 ` Uday Shankar [this message]
2025-04-16 0:59 ` [PATCH v4 3/4] ublk: mark ublk_queue as const for ublk_register_io_buf Uday Shankar
2025-04-16 19:12 ` Caleb Sander Mateos
2025-04-16 0:59 ` [PATCH v4 4/4] ublk: mark ublk_queue as const for ublk_handle_need_get_data Uday Shankar
2025-04-16 19:26 ` Caleb Sander Mateos
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 \
--in-reply-to=aAAEoifl5tAocAYq@dev-ushankar.dev.purestorage.com \
--to=ushankar@purestorage.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
/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
all inboxes | Powered by JetHome®