From: sashiko-bot@kernel.org
To: "Daniel Wagner" <dwagner@suse.de>
Cc: linux-nvme@lists.infradead.org
Subject: Re: [PATCH v2] blk-mq: use a housekeeping CPU for passthrough requests on isolated hctxs
Date: Tue, 03 Nov 2026 15:22:29 +0000 [thread overview]
Message-ID: <sashiko-outbox-195610@kernel.org> (raw)
In-Reply-To: <20261103-nvme-fabrics-isolcpu-v2-1-95ec70d58254@suse.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] blk-mq: blk_mq_alloc_request_hctx() allocates on offline hctxs when BLK_MQ_S_INACTIVE is unset
--
commit f6824e249591ee431516fa47caa778074d8f4d22
Author: Daniel Wagner <dwagner@suse.de>
blk-mq: use a housekeeping CPU for passthrough requests on isolated hctxs
When hctx->cpumask contains no online CPUs because all CPUs mapped to the
hardware context are isolated, this commit allows passthrough requests in
blk_mq_alloc_request_hctx() to fall back to the software context of an
online housekeeping CPU unless BLK_MQ_S_INACTIVE is set on the hctx.
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 5fca78778c31c..77685e6283fa1 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
[ ... ]
> @@ -767,8 +786,22 @@ struct request *blk_mq_alloc_request_hctx(struct request_queue *q,
> if (!blk_mq_hw_queue_mapped(data.hctx))
> goto out_queue_exit;
> cpu = cpumask_first_and(data.hctx->cpumask, cpu_online_mask);
> - if (cpu >= nr_cpu_ids)
> - goto out_queue_exit;
> + if (cpu >= nr_cpu_ids) {
> + /*
> + * Isolated CPUs are not part of hctx->cpumask, so it can be
> + * empty although online CPUs are mapped to this hardware
> + * context. Passthrough requests are inserted directly into
> + * hctx->dispatch, so use the software context of a
> + * housekeeping CPU for them. Inactive hardware contexts have
> + * no online CPU left.
> + */
> + if (!blk_op_is_passthrough(opf) ||
> + test_bit(BLK_MQ_S_INACTIVE, &data.hctx->state))
> + goto out_queue_exit;
> + cpu = blk_mq_housekeeping_cpu();
> + if (cpu >= nr_cpu_ids)
> + goto out_queue_exit;
> + }
[Severity: Medium]
Can this allocate a passthrough request on a hardware context that has no
online CPUs mapped to it instead of returning ERR_PTR(-EXDEV)?
BLK_MQ_S_INACTIVE is only set in the CPU hotplug callback
blk_mq_hctx_notify_offline() when the last online CPU mapped to an hctx
transitions to offline:
block/blk-mq.c:blk_mq_hctx_notify_offline() {
...
if (!hctx->nr_ctx || blk_mq_hctx_has_online_cpu(hctx, cpu))
return 0;
set_bit(BLK_MQ_S_INACTIVE, &hctx->state);
...
}
However, during queue initialization in blk_mq_init_allocated_queue() and
queue reconfiguration in blk_mq_update_nr_hw_queues(), blk_mq_init_hctx()
unconditionally clears BLK_MQ_S_INACTIVE, __blk_mq_add_cpuhp() registers the
hotplug state via cpuhp_state_add_instance_nocalls() (and skips registration
for BLK_MQ_F_STACKING), and blk_mq_map_swqueue() maps all present and
possible CPUs to hardware contexts without setting BLK_MQ_S_INACTIVE on
hctxs whose mapped CPUs are all currently offline.
If a queue is initialized or remapped while all CPUs assigned to data.hctx
are already offline, blk_mq_hw_queue_mapped(data.hctx) is true and
BLK_MQ_S_INACTIVE remains clear. When blk_mq_alloc_request_hctx() is called
for that hctx_idx with a passthrough operation, test_bit(BLK_MQ_S_INACTIVE,
&data.hctx->state) evaluates to false and the request is allocated using
blk_mq_housekeeping_cpu() on an offline hardware queue instead of failing
with -EXDEV.
Should this check !blk_mq_hctx_has_online_cpu(data.hctx, nr_cpu_ids) (or
ensure blk_mq_map_swqueue() sets BLK_MQ_S_INACTIVE when an hctx has no
online CPUs mapped)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261103-nvme-fabrics-isolcpu-v2-1-95ec70d58254@suse.de?part=1
next prev parent reply other threads:[~2026-11-03 15:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 14:57 [PATCH v2] blk-mq: use a housekeeping CPU for passthrough requests on isolated hctxs Daniel Wagner
2026-11-03 15:22 ` sashiko-bot [this message]
2026-11-04 10:22 ` Daniel Wagner
2026-11-04 13:55 ` Daniel Wagner
2026-11-03 15:50 ` Aaron Tomlin
2026-11-03 16:37 ` Sebastian Andrzej Siewior
2026-11-04 7:17 ` Christoph Hellwig
2026-11-04 7:37 ` Sebastian Andrzej Siewior
2026-11-04 7:45 ` Christoph Hellwig
2026-11-03 17:04 ` Nilay Shroff
2026-11-04 7:17 ` Christoph Hellwig
2026-11-04 7:47 ` Hannes Reinecke
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=sashiko-outbox-195610@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dwagner@suse.de \
--cc=linux-nvme@lists.infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.