Re: [GIT PULL] SCSI fixes for 7.3-rc3+

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] block: hardcoded index 0 ignores queue_offset in fnic_mq_init_queue_map()
--

commit fb10ad8a27ba0b6671190a2c5e8966d7c784afce
Author: James Bottomley <James.Bottomley@HansenPartnership.com>

SCSI fixes for 7.3-rc3+

This commit pulls in four driver fixes and one core fix. It includes a fix in
the fnic driver to add logic avoiding ineffective MSI-X when hyperthreading is
disabled, as well as a core fix validating mode sense buffer sizes.

> diff --git a/drivers/scsi/fnic/fnic_main.c b/drivers/scsi/fnic/fnic_main.c
> index 9b3025007075e..f13c381a66d7f 100644
> --- a/drivers/scsi/fnic/fnic_main.c
> +++ b/drivers/scsi/fnic/fnic_main.c
> @@ -744,8 +744,19 @@ static int fnic_nvme_drv_init(struct fnic *fnic)
>  	return ret;
>  }
>  
> +static void fnic_mq_init_queue_map(struct fnic *fnic,
> +		struct blk_mq_queue_map *qmap)
> +{
> +	unsigned int cpu;
> +
> +	for_each_possible_cpu(cpu)
> +		qmap->mq_map[cpu] = 0;

[Severity: Low]
Does this hardcoded index 0 in fnic_mq_init_queue_map() ignore the
queue_offset field provided by the block layer?

If multiple queue maps (like READ/POLL) were ever used, hardcoding 0 instead
of using qmap->queue_offset would violate the block layer API for hardware
queue mapping, routing unassigned CPUs to the tagset's absolute 0th queue
instead of the 0th queue of the correct map.

Because the fnic driver currently sets up only a single default tagset map
(HCTX_TYPE_DEFAULT) where queue_offset is always 0, this doesn't trigger
a functional bug today. But should this be updated to use qmap->queue_offset
for API correctness and future-proofing?

> +}
> +
>  void fnic_mq_map_queues_cpus(struct Scsi_Host *host)
>  {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/71da251528b9af2948fb5a4c8bcd045e65b3e42e.camel@HansenPartnership.com?part=1