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,
Uday Shankar <ushankar@purestorage.com>,
Keith Busch <kbusch@kernel.org>,
io-uring@vger.kernel.org
Subject: Re: [PATCH 01/13] ublk: delay aborting zc request until io_uring returns the buffer
Date: Tue, 8 Apr 2025 10:18:21 +0800 [thread overview]
Message-ID: <Z_SHbVr3QM9Ay3ed@fedora> (raw)
In-Reply-To: <CADUfDZodKfOGUeWrnAxcZiLT+puaZX8jDHoj_sfHZCOZwhzz6A@mail.gmail.com>
On Mon, Apr 07, 2025 at 08:02:24AM -0700, Caleb Sander Mateos wrote:
> On Mon, Apr 7, 2025 at 6:15 AM Ming Lei <ming.lei@redhat.com> wrote:
> >
> > When one request buffer is leased to io_uring via
> > io_buffer_register_bvec(), io_uring guarantees that the buffer will
> > be returned. However ublk aborts request in case that io_uring context
> > is exiting, then ublk_io_release() may observe freed request, and
> > kernel panic is triggered.
>
> Not sure I follow how the request can be freed while its buffer is
> still registered with io_uring. It looks like __ublk_fail_req()
> decrements the ublk request's reference count (ublk_put_req_ref()) and
> the reference count shouldn't hit 0 if the io_uring registered buffer
> is still holding a reference. Is the problem the if
> (ublk_nosrv_should_reissue_outstanding()) case, which calls
> blk_mq_requeue_request() without checking the reference count?
Yeah, that is the problem, the request can be failed immediately after
requeue & re-dispatch, then trigger the panic, and I verified that the
following patch does fix it:
diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 2fd05c1bd30b..41bed67508f2 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -1140,6 +1140,25 @@ static void ublk_complete_rq(struct kref *ref)
__ublk_complete_rq(req);
}
+static void ublk_do_fail_rq(struct request *req)
+{
+ struct ublk_queue *ubq = req->mq_hctx->driver_data;
+
+ if (ublk_nosrv_should_reissue_outstanding(ubq->dev))
+ blk_mq_requeue_request(req, false);
+ else
+ __ublk_complete_rq(req);
+}
+
+static void ublk_fail_rq_fn(struct kref *ref)
+{
+ struct ublk_rq_data *data = container_of(ref, struct ublk_rq_data,
+ ref);
+ struct request *req = blk_mq_rq_from_pdu(data);
+
+ ublk_do_fail_rq(req);
+}
+
/*
* Since ublk_rq_task_work_cb always fails requests immediately during
* exiting, __ublk_fail_req() is only called from abort context during
@@ -1153,10 +1172,13 @@ static void __ublk_fail_req(struct ublk_queue *ubq, struct ublk_io *io,
{
WARN_ON_ONCE(io->flags & UBLK_IO_FLAG_ACTIVE);
- if (ublk_nosrv_should_reissue_outstanding(ubq->dev))
- blk_mq_requeue_request(req, false);
- else
- ublk_put_req_ref(ubq, req);
+ if (ublk_need_req_ref(ubq)) {
+ struct ublk_rq_data *data = blk_mq_rq_to_pdu(req);
+
+ kref_put(&data->ref, ublk_fail_rq_fn);
+ } else {
+ ublk_do_fail_rq(req);
+ }
}
static void ubq_complete_io_cmd(struct ublk_io *io, int res,
Thanks,
Ming
next prev parent reply other threads:[~2025-04-08 2:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 13:15 [PATCH 00/13] ublk: one driver bug fix and selftest change Ming Lei
2025-04-07 13:15 ` [PATCH 01/13] ublk: delay aborting zc request until io_uring returns the buffer Ming Lei
2025-04-07 15:02 ` Caleb Sander Mateos
2025-04-08 2:18 ` Ming Lei [this message]
2025-04-07 13:15 ` [PATCH 02/13] selftests: ublk: fix ublk_find_tgt() Ming Lei
2025-04-08 6:05 ` Johannes Thumshirn
2025-04-12 1:25 ` Ming Lei
2025-04-07 13:15 ` [PATCH 03/13] selftests: ublk: add io_uring uapi header Ming Lei
2025-04-08 6:08 ` Johannes Thumshirn
2025-04-07 13:15 ` [PATCH 04/13] selftests: ublk: cleanup backfile automatically Ming Lei
2025-04-07 13:15 ` [PATCH 05/13] selftests: ublk: make sure _add_ublk_dev can return in sub-shell Ming Lei
2025-04-07 13:15 ` [PATCH 06/13] selftests: ublk: run stress tests in parallel Ming Lei
2025-04-07 13:15 ` [PATCH 07/13] selftests: ublk: add two stress tests for zero copy feature Ming Lei
2025-04-07 13:15 ` [PATCH 08/13] selftests: ublk: setup ring with IORING_SETUP_SINGLE_ISSUER/IORING_SETUP_DEFER_TASKRUN Ming Lei
2025-04-07 13:15 ` [PATCH 09/13] selftests: ublk: set queue pthread's cpu affinity Ming Lei
2025-04-07 13:15 ` [PATCH 10/13] selftests: ublk: increase max nr_queues and queue depth Ming Lei
2025-04-07 13:15 ` [PATCH 11/13] selftests: ublk: support target specific command line Ming Lei
2025-04-07 13:15 ` [PATCH 12/13] selftests: ublk: support user recovery Ming Lei
2025-04-07 13:15 ` [PATCH 13/13] selftests: ublk: add test_stress_05.sh Ming Lei
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=Z_SHbVr3QM9Ay3ed@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=io-uring@vger.kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--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 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.