]> git.ipfire.org Git - thirdparty/linux.git/commit
scsi: storvsc: Don't assume cpu_possible_mask is dense
authorMichael Kelley <mhklinux@outlook.com>
Thu, 3 Oct 2024 03:53:32 +0000 (20:53 -0700)
committerMartin K. Petersen <martin.petersen@oracle.com>
Tue, 10 Dec 2024 02:57:52 +0000 (21:57 -0500)
commit6cb7063feb2eff2e52dc9624b2193a1f4cad69bf
tree9641d10e6b5873141baf4cf26ae3940b80564056
parentbd55f56188caf170d6dbdc04638159bd91d8401b
scsi: storvsc: Don't assume cpu_possible_mask is dense

Current code allocates the stor_chns array with size num_possible_cpus().
This code assumes cpu_possible_mask is dense, which is not true in the
general case per [1]. If cpu_possible_mask is sparse, the array might be
indexed by a value beyond the size of the array.

However, the configurations that Hyper-V provides to guest VMs on x86 and
ARM64 hardware, in combination with how architecture specific code assigns
Linux CPU numbers, *does* always produce a dense cpu_possible_mask.  So the
dense assumption is not currently causing failures. But for robustness
against future changes in how cpu_possible_mask is populated, update the
code to no longer assume dense.

The correct approach is to allocate and initialize the array using size
"nr_cpu_ids". While this leaves unused array entries corresponding to holes
in cpu_possible_mask, the holes are assumed to be minimal and hence the
amount of memory wasted by unused entries is minimal.

[1] https://lore.kernel.org/lkml/SN6PR02MB4157210CC36B2593F8572E5ED4692@SN6PR02MB4157.namprd02.prod.outlook.com/

Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/20241003035333.49261-5-mhklinux@outlook.com
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/storvsc_drv.c