[PATCH v2] blk-mq: use a housekeeping CPU for passthrough requests on isolated hctxs

[Daniel Wagner]

On Wed, Nov 04, 2026 at 11:22:40AM +0100, Daniel Wagner wrote:
> On Tue, Nov 03, 2026 at 03:22:29PM +0000, sashiko-bot at kernel.org wrote:
> > 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)?
> 
> Yes, this is correct. I'll extend the patch and add this to the commit message:
> 
>     When all mapped CPUs are offline at queue setup, BLK_MQ_S_INACTIVE is
>     not set, as only the CPU offline callback sets it. The
>     blk_mq_hctx_has_online_cpu test catches this case. It uses the queue
>     map, so it also finds online isolated CPUs.
> 
>     When the last mapped CPU goes offline, the CPU offline callback sets
>     BLK_MQ_S_INACTIVE while the CPU is still in cpu_online_mask, so
>     blk_mq_hctx_has_online_cpu still finds it. The BLK_MQ_S_INACTIVE test
>     catches this case.

I have to correct myself. Allocating on a hardware context with only
offline CPUs is intended, so the patch shouldn't add the check.

blk-mq maps all possible CPUs to the hardware contexts since
20e4d8139319 ("blk-mq: simplify queue mapping & schedule with each
possisble CPU"). While CPUs are offline, a hardware context can end up
with only offline CPUs. blk_mq_alloc_request_hctx() then fails the
Connect command with -EXDEV, and connecting a fabrics controller fails,
for example when booted with maxcpus=4 on an 8-CPU machine. The queue is
still needed once the CPUs come online.

I wrote a blktest for this (nvme/080). It fails on current upstream.
With the patch the connect works, and I/O from the CPUs goes through
that queue after they come online. Hardware contexts whose last CPU
went offline are inactive and still fail.

v3 keeps the v2 code and adds this case to the commit message, with a
second Fixes tag for 20e4d8139319.