From: Jens Axboe <axboe@kernel.dk>
To: Ming Lei <ming.lei@redhat.com>
Cc: linux-block@vger.kernel.org,
Caleb Sander Mateos <csander@purestorage.com>,
Uday Shankar <ushankar@purestorage.com>,
Ming Lei <ming.lei@redhat.com>
Subject: Re: [PATCH V6 07/24] ublk: add batch I/O dispatch infrastructure
Date: Thu, 22 Jan 2026 20:32:25 -0700 [thread overview]
Message-ID: <a56a1182-72da-47ff-98fc-d1d33afcd557@kernel.dk> (raw)
In-Reply-To: <20260116141859.719929-8-ming.lei@redhat.com>
Claude says:
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index e5db5a552357..e7bd7e7b1731 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
[ ... ]
> +static bool __ublk_batch_prep_dispatch(struct ublk_queue *ubq,
> + const struct ublk_batch_io_data *data,
> + unsigned short tag)
> +{
> + struct ublk_device *ub = data->ub;
> + struct ublk_io *io = &ubq->ios[tag];
> + struct request *req = blk_mq_tag_to_rq(ub->tag_set.tags[ubq->q_id], tag);
> + enum auto_buf_reg_res res = AUTO_BUF_REG_FALLBACK;
> + struct io_uring_cmd *cmd = data->cmd;
> +
> + if (!ublk_start_io(ubq, req, io))
> + return false;
> +
> + if (ublk_support_auto_buf_reg(ubq) && ublk_rq_has_data(req)) {
> + res = __ublk_do_auto_buf_reg(ubq, req, io, cmd,
> + data->issue_flags);
> +
> + if (res == AUTO_BUF_REG_FAIL)
> + return false;
> + }
> +
> + ublk_io_lock(io);
> + ublk_prep_auto_buf_reg_io(ubq, req, io, cmd, res);
> + ublk_io_unlock(io);
> +
> + return true;
> +}
[ ... ]
> +#define MAX_NR_TAG 128
> +static int __ublk_batch_dispatch(struct ublk_queue *ubq,
> + const struct ublk_batch_io_data *data,
> + struct ublk_batch_fetch_cmd *fcmd)
> +{
[ ... ]
> + sel.val = ublk_batch_copy_io_tags(fcmd, sel.addr, tag_buf, len * tag_sz);
> + ret = ublk_batch_fetch_post_cqe(fcmd, &sel, data->issue_flags);
> + if (unlikely(ret < 0)) {
> + int i, res;
> +
> + /*
> + * Undo prep state for all IOs since userspace never received them.
> + * This restores IOs to pre-prepared state so they can be cleanly
> + * re-prepared when tags are pulled from FIFO again.
> + */
> + for (i = 0; i < len; i++) {
> + struct ublk_io *io = &ubq->ios[tag_buf[i]];
> + int index = -1;
> +
> + ublk_io_lock(io);
> + if (io->flags & UBLK_IO_FLAG_AUTO_BUF_REG)
> + index = io->buf.auto_reg.index;
> + io->flags &= ~(UBLK_IO_FLAG_OWNED_BY_SRV | UBLK_IO_FLAG_AUTO_BUF_REG);
> + io->flags |= UBLK_IO_FLAG_ACTIVE;
> + ublk_io_unlock(io);
> +
> + if (index != -1)
> + io_buffer_unregister_bvec(data->cmd, index,
> + data->issue_flags);
> + }
Should io->task_registered_buffers also be cleared here?
When __ublk_batch_prep_dispatch() succeeds with AUTO_BUF_REG_OK, the call to
ublk_prep_auto_buf_reg_io() sets io->task_registered_buffers = 1. In this
error recovery path, the buffer is unregistered and UBLK_IO_FLAG_AUTO_BUF_REG
is cleared, but task_registered_buffers is not reset to 0.
If the tag is later re-dispatched and __ublk_do_auto_buf_reg() returns
AUTO_BUF_REG_FALLBACK (e.g., due to -ENOMEM), task_registered_buffers will
remain at 1 even though no buffer is actually registered.
This could affect ublk_sub_req_ref() which calculates:
sub_refs = UBLK_REFCOUNT_INIT - io->task_registered_buffers
If task_registered_buffers is incorrectly 1 when it should be 0, the
refcount subtraction would leave an extra reference, potentially causing
the IO to never complete.
--
Jens Axboe
next prev parent reply other threads:[~2026-01-23 3:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 14:18 [PATCH V6 00/24] ublk: add UBLK_F_BATCH_IO Ming Lei
2026-01-16 14:18 ` [PATCH V6 01/24] ublk: define ublk_ch_batch_io_fops for the coming feature F_BATCH_IO Ming Lei
2026-01-16 14:18 ` [PATCH V6 02/24] ublk: prepare for not tracking task context for command batch Ming Lei
2026-01-16 14:18 ` [PATCH V6 03/24] ublk: add new batch command UBLK_U_IO_PREP_IO_CMDS & UBLK_U_IO_COMMIT_IO_CMDS Ming Lei
2026-01-16 14:18 ` [PATCH V6 04/24] ublk: handle UBLK_U_IO_PREP_IO_CMDS Ming Lei
2026-01-23 3:31 ` Jens Axboe
2026-01-16 14:18 ` [PATCH V6 05/24] ublk: handle UBLK_U_IO_COMMIT_IO_CMDS Ming Lei
2026-01-16 14:18 ` [PATCH V6 06/24] ublk: add io events fifo structure Ming Lei
2026-01-16 14:18 ` [PATCH V6 07/24] ublk: add batch I/O dispatch infrastructure Ming Lei
2026-01-23 3:32 ` Jens Axboe [this message]
2026-01-23 8:10 ` Ming Lei
2026-01-16 14:18 ` [PATCH V6 08/24] ublk: add UBLK_U_IO_FETCH_IO_CMDS for batch I/O processing Ming Lei
2026-01-16 14:18 ` [PATCH V6 09/24] ublk: refactor ublk_queue_rq() and add ublk_batch_queue_rq() Ming Lei
2026-01-23 3:04 ` Caleb Sander Mateos
2026-01-16 14:18 ` [PATCH V6 10/24] ublk: abort requests filled in event kfifo Ming Lei
2026-01-16 14:18 ` [PATCH V6 11/24] ublk: add new feature UBLK_F_BATCH_IO Ming Lei
2026-01-16 14:18 ` [PATCH V6 12/24] ublk: document " Ming Lei
2026-01-16 14:18 ` [PATCH V6 13/24] ublk: implement batch request completion via blk_mq_end_request_batch() Ming Lei
2026-01-16 14:18 ` [PATCH V6 14/24] ublk: fix batch I/O recovery -ENODEV error Ming Lei
2026-01-23 3:33 ` Jens Axboe
2026-01-16 14:18 ` [PATCH V6 15/24] selftests: ublk: fix user_data truncation for tgt_data >= 256 Ming Lei
2026-01-16 14:18 ` [PATCH V6 16/24] selftests: ublk: replace assert() with ublk_assert() Ming Lei
2026-01-16 14:18 ` [PATCH V6 17/24] selftests: ublk: add ublk_io_buf_idx() for returning io buffer index Ming Lei
2026-01-16 14:18 ` [PATCH V6 18/24] selftests: ublk: add batch buffer management infrastructure Ming Lei
2026-01-16 14:18 ` [PATCH V6 19/24] selftests: ublk: handle UBLK_U_IO_PREP_IO_CMDS Ming Lei
2026-01-16 14:18 ` [PATCH V6 20/24] selftests: ublk: handle UBLK_U_IO_COMMIT_IO_CMDS Ming Lei
2026-01-16 14:18 ` [PATCH V6 21/24] selftests: ublk: handle UBLK_U_IO_FETCH_IO_CMDS Ming Lei
2026-01-16 14:18 ` [PATCH V6 22/24] selftests: ublk: increase timeout to 150 seconds Ming Lei
2026-01-16 14:18 ` [PATCH V6 23/24] selftests: ublk: add --batch/-b for enabling F_BATCH_IO Ming Lei
2026-01-16 14:18 ` [PATCH V6 24/24] selftests: ublk: support arbitrary threads/queues combination Ming Lei
2026-01-23 2:24 ` [PATCH V6 00/24] ublk: add UBLK_F_BATCH_IO Ming Lei
2026-01-23 3:06 ` 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=a56a1182-72da-47ff-98fc-d1d33afcd557@kernel.dk \
--to=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=ushankar@purestorage.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