All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.