linux-kernel - Re: [PATCH] ublk: restore auto buf unregister refcount optimization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADUfDZqH9NZrQGOkYP9cpWRVkhPT9uiPc3XUfW6X4G=97oeE9w@mail.gmail.com>
Date: Wed, 28 Jan 2026 13:08:17 -0800
From: Caleb Sander Mateos <csander@...estorage.com>
To: Ming Lei <ming.lei@...hat.com>, Jens Axboe <axboe@...nel.dk>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ublk: restore auto buf unregister refcount optimization

On Wed, Jan 28, 2026 at 12:56 PM Caleb Sander Mateos
<csander@...estorage.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@...estorage.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?
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.

Thanks,
Caleb