From: Benjamin Marzinski <bmarzins@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Martin Wilck <mwilck@suse.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
dm-devel@lists.linux.dev, linux-block@vger.kernel.org
Subject: Re: [PATCH] dm: Fix deadlock when reloading a multipath table
Date: Thu, 9 Oct 2025 20:39:35 -0400 [thread overview]
Message-ID: <aOhVx3J2ahZQuS28@redhat.com> (raw)
In-Reply-To: <033ca444-4c68-4a4f-bc2b-32232e80e848@acm.org>
On Thu, Oct 09, 2025 at 04:29:21PM -0700, Bart Van Assche wrote:
> On 10/9/25 2:57 AM, Martin Wilck wrote:
> > In general, I'm wondering whether we need a more generic solution to
> > this problem. Therefore I've added linux-block to cc.
> >
> > The way I see it, if a device has queued IO without any means to
> > perform the IO, it can't be frozen. We'd either need to fail all queued
> > IO in this case, or refuse attempts to freeze the queue.
>
> If a device has queued I/O and the I/O can't make progress then it isn't
> necessary to call blk_mq_freeze_queue(), isn't it? See also "[PATCH 0/3] Fix
> a deadlock related to modifying queue attributes"
> (https://lore.kernel.org/linux-block/20250702182430.3764163-1-bvanassche@acm.org/).
>
> BTW, that patch series is not upstream. I apply it manually every time
> before I run blktests.
Timing out the queue freeze looks like a good solution to me.
Also, looking at that thread, I should point out that bio-based
multipath does not suffer from this, since it doesn't queue requests. It
queues bios. The reason you still got the hang with your blktests patch
is that it didn't actually configure bio-based multipath ("queue_mode"
is not a valid multipath.conf option). That would look something like
this:
===================
diff --git a/common/multipath-over-rdma b/common/multipath-over-rdma
index e157e0a..1084f80 100644
--- a/common/multipath-over-rdma
+++ b/common/multipath-over-rdma
@@ -267,9 +267,7 @@ mpath_has_stale_dev() {
# Check whether multipath definition $1 includes the queue_if_no_path keyword.
is_qinp_def() {
case "$1" in
- *" 3 queue_if_no_path queue_mode mq "*)
- return 0;;
- *" 1 queue_if_no_path "*)
+ *" queue_if_no_path "*)
return 0;;
*)
return 1;;
diff --git a/tests/srp/multipath.conf b/tests/srp/multipath.conf
index e0da32e..aad8e56 100644
--- a/tests/srp/multipath.conf
+++ b/tests/srp/multipath.conf
@@ -9,6 +9,7 @@ devices {
product ".*"
no_path_retry queue
path_checker tur
+ features "2 queue_mode bio"
}
}
blacklist {
==================
But you are correct that unless we can get bio-based multipath to
something like performance parity with request-based multipath,
customers aren't interested it in.
-Ben
>
> Bart.
next prev parent reply other threads:[~2025-10-10 0:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251009030431.2895495-1-bmarzins@redhat.com>
2025-10-09 9:57 ` [PATCH] dm: Fix deadlock when reloading a multipath table Martin Wilck
2025-10-09 22:25 ` Benjamin Marzinski
2025-10-10 10:19 ` Martin Wilck
2025-10-21 19:16 ` Benjamin Marzinski
2025-10-22 14:11 ` Martin Wilck
2025-10-23 17:39 ` Benjamin Marzinski
2025-10-23 17:54 ` Bart Van Assche
2025-10-09 23:29 ` Bart Van Assche
2025-10-10 0:39 ` Benjamin Marzinski [this message]
2025-10-10 9:23 ` Martin Wilck
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=aOhVx3J2ahZQuS28@redhat.com \
--to=bmarzins@redhat.com \
--cc=bvanassche@acm.org \
--cc=dm-devel@lists.linux.dev \
--cc=linux-block@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=mwilck@suse.com \
--cc=snitzer@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;
as well as URLs for NNTP newsgroup(s).