Re: [PATCH v15 5/8] blk-mq: use hk cpus only when isolcpus=io_queue is enabled

[Aaron Tomlin]

On Tue, Jul 21, 2026 at 12:28:04PM +0200, Marco Crivellari wrote:
> Hi,
> 
> On Fri, May 22, 2026 at 1:30 AM Aaron Tomlin <atomlin@xxxxxxxxxxx> wrote:
> > + void blk_mq_map_queues(struct blk_mq_queue_map *qmap)
> > [..]
> > +       /*
> > +        * Snapshot online CPUs to prevent TOCTOU races between the
> > +        * mapping phase and the validation phase.
> > +        */
> > +       cpumask_copy(online_mask, cpu_online_mask);
> 
> I'm wondering: should this code be protected somehow, maybe directly
> by the caller (eg w/ cpus_read_lock()) to avoid a CPU going offline eg
> after the copy?
> This invalidates the copy because a CPU set there might have gone
> offline, and the blk code would then still use that CPU.
> 
> Does that make sense or it is not the case?
> 
> Thanks!

Hi Marco,

Thank you for reviewing the patch and raising this point!

Yes, taking a lockless snapshot via cpumask_copy(online_mask,
cpu_online_mask) introduces a TOCTOU race, as a CPU could go offline
immediately after the copy, leaving online_mask stale during validation.

Rather than introducing cpus_read_lock() into block/ to protect a dynamic
cpu_online_mask sample, a cleaner solution is to align blk_mq_map_queues()
with existing blk-mq architectural patterns.

    1.  Refactor blk_mq_map_queues() to build mappings using the static
        housekeeping mask intersected with cpu_present_mask (or
        cpu_possible_mask), removing the dynamic cpu_online_mask snapshot
        and blk_mq_validate() check altogether

    2.  Rely on blk_mq_hctx_notify_offline()—introduced in patch 4/8 of
        this series—to enforce runtime hotplug safety. The function
        blk_mq_hctx_notify_offline() already runs under cpus_write_lock()
        during CPU hotplug and explicitly prevents offlining the final
        housekeeping CPU serving an active isolated CPU


Kind regards,
--
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature