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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>

0 files changed, 0 insertions, 0 deletions