From: Nirmoy Das <nirmoyd@nvidia.com>
To: <axboe@kernel.dk>
Cc: <lev@zadarastorage.com>, <kbusch@kernel.org>,
<tom.leiming@gmail.com>, <yukuai@fygo.io>,
<linux-block@vger.kernel.org>, <linux-nvme@lists.infradead.org>,
<regressions@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
Nirmoy Das <nirmoyd@nvidia.com>, <stable@vger.kernel.org>
Subject: [PATCH] blk-mq: restore shared-tag flag after hctx reallocation
Date: Tue, 20 Oct 2026 10:44:35 -0700 [thread overview]
Message-ID: <20261020174435.1527425-1-nirmoyd@nvidia.com> (raw)
__blk_mq_update_nr_hw_queues() reallocates the hctxs of queues already
on set->tag_list, so blk_mq_add_queue_tag_set() never sets
BLK_MQ_F_TAG_QUEUE_SHARED on them again. A new hctx starts without the
bit and a reused hctx keeps whatever it had when it was parked. An
NVMe/TCP controller reset goes through this path.
With the bit clear and an I/O scheduler, blk_mq_mark_tag_wait() sets
SCHED_RESTART without adding a tag waiter and relies on a completion on
the same hctx to run the queue again. If other queues on the set hold
all the driver tags, this hctx has nothing in flight. Once its
submitters block on scheduler tags, nothing runs it again and I/O
hangs.
Reapply the tag set's shared state after reallocating the hctxs, while
the queues are still frozen.
Reproduced on v7.3 in an arm64 QEMU/KVM guest with a loopback NVMe/TCP
target, four namespaces and mq-deadline. After one controller reset all
four namespaces lost TAG_QUEUE_SHARED and fio stalled. With this change
the bit survives five resets, and fio completes after a reset.
Fixes: 868f2f0b7206 ("blk-mq: dynamic h/w context count")
Reported-by: Lev <lev@zadarastorage.com>
Closes: https://lore.kernel.org/all/00cb01dd3099$c82b66c0$58823440$@zadarastorage.com/
Cc: stable@vger.kernel.org
Assisted-by: LLM Specula
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
---
block/blk-mq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 00b75eb95dd943a..ec3a7e5300d0e31 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -5188,6 +5188,7 @@ static void __blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set,
set->nr_hw_queues = prev_nr_hw_queues;
goto fallback;
}
+ queue_set_hctx_shared(q, set->flags & BLK_MQ_F_TAG_QUEUE_SHARED);
blk_mq_map_swqueue(q);
}
switch_back:
--
2.43.0
reply other threads:[~2026-10-20 17:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261020174435.1527425-1-nirmoyd@nvidia.com \
--to=nirmoyd@nvidia.com \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--cc=lev@zadarastorage.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=tom.leiming@gmail.com \
--cc=yukuai@fygo.io \
/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
all inboxes | Powered by JetHome®