public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ublk: restore auto buf unregister refcount optimization
Date: Thu, 29 Jan 2026 10:39:47 +0800	[thread overview]
Message-ID: <aXrIc3pZ-h_hME8_@fedora> (raw)
In-Reply-To: <CADUfDZqH9NZrQGOkYP9cpWRVkhPT9uiPc3XUfW6X4G=97oeE9w@mail.gmail.com>

On Wed, Jan 28, 2026 at 01:08:17PM -0800, Caleb Sander Mateos wrote:
> On Wed, Jan 28, 2026 at 12:56 PM Caleb Sander Mateos
> <csander@purestorage.com> wrote:
> >
> > Commit 1ceeedb59749 ("ublk: optimize UBLK_IO_UNREGISTER_IO_BUF on daemon
> > task") optimized ublk request buffer unregistration to use a non-atomic
> > reference count decrement when performed on the ublk_io's daemon task.
> > The optimization applied to auto buffer unregistration, which happens as
> > part of handling UBLK_IO_COMMIT_AND_FETCH_REQ on the daemon task.
> > However, commit b749965edda8 ("ublk: remove ublk_commit_and_fetch()")
> > reordered the ublk_sub_req_ref() for the completed request before the
> > io_buffer_unregister_bvec() call. As a result, task_registered_buffers
> > is already 0 when io_buffer_unregister_bvec() calls ublk_io_release()
> > and the non-atomic refcount optimization doesn't apply.
> > Move the io_buffer_unregister_bvec() call back to before
> > ublk_need_complete_req() to restore the reference counting optimization.
> >
> > Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
> > Fixes: b749965edda8 ("ublk: remove ublk_commit_and_fetch()")
> > ---
> >  drivers/block/ublk_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> > index 7981decd1cee..f864a0f2f572 100644
> > --- a/drivers/block/ublk_drv.c
> > +++ b/drivers/block/ublk_drv.c
> > @@ -3243,15 +3243,15 @@ static int ublk_ch_uring_cmd_local(struct io_uring_cmd *cmd,
> >                 if (ret)
> >                         goto out;
> >                 io->res = result;
> >                 req = ublk_fill_io_cmd(io, cmd);
> >                 ret = ublk_config_io_buf(ub, io, cmd, addr, &buf_idx);
> > +               if (buf_idx != UBLK_INVALID_BUF_IDX)
> > +                       io_buffer_unregister_bvec(cmd, buf_idx, issue_flags);
> >                 compl = ublk_need_complete_req(ub, io);
> >
> >                 /* can't touch 'ublk_io' any more */
> > -               if (buf_idx != UBLK_INVALID_BUF_IDX)
> > -                       io_buffer_unregister_bvec(cmd, buf_idx, issue_flags);
> >                 if (req_op(req) == REQ_OP_ZONE_APPEND)
> >                         req->__sector = addr;
> >                 if (compl)
> >                         __ublk_complete_rq(req, io, ublk_dev_need_map_io(ub), NULL);
> 
> I also noticed that the "can't touch 'ublk_io' any more" comment
> doesn't make much sense, as __ublk_complete_rq() still accesses (and
> even mutates) the struct ublk_io. Am I misunderstanding the comment?

Yes, it can be removed, originally this code block may be reused for
BATCH_IO, but finally it doesn't work toward this way, so can you remove
it in this patch given it is introduced in b749965edda8 ("ublk: remove ublk_commit_and_fetch()")?

> It looks like this might be a race condition for
> UBLK_U_IO_COMMIT_IO_CMDS, as __ublk_complete_rq() is called without
> holding the ublk_io spinlock.

It is actually fine for __ublk_complete_rq() to manipulate io->res lockless:

1) UBLK_IO_FLAG_OWNED_BY_SRV is cleared & checked with io->lock, so any new
UBLK_U_IO_COMMIT_IO_CMDS will be failed

2) the current IO request isn't completed yet, so new io command handling
won't be started.


Thanks,
Ming


  reply	other threads:[~2026-01-29  2:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-28 20:56 [PATCH] ublk: restore auto buf unregister refcount optimization Caleb Sander Mateos
2026-01-28 21:08 ` Caleb Sander Mateos
2026-01-29  2:39   ` Ming Lei [this message]
2026-01-30  2:36 ` Ming Lei
2026-01-30 15:12 ` Jens Axboe

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=aXrIc3pZ-h_hME8_@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=csander@purestorage.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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