diff mbox series

[4/5] scsi: storvsc: Don't assume cpu_possible_mask is dense

Message ID 20241003035333.49261-5-mhklinux@outlook.com (mailing list archive)
State Not Applicable
Delegated to: Netdev Maintainers
Headers show
Series hyper-v: Don't assume cpu_possible_mask is dense | expand

Checks

Context Check Description
netdev/series_format success Posting correctly formatted
netdev/tree_selection success Guessed tree name to be net-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 9 this patch: 9
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers success CCed 8 of 8 maintainers
netdev/build_clang success Errors and warnings before: 9 this patch: 9
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 8 this patch: 8
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 20 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
netdev/contest success net-next-2024-10-04--18-00 (tests: 773)

Commit Message

Michael Kelley Oct. 3, 2024, 3:53 a.m. UTC
From: Michael Kelley <mhklinux@outlook.com>

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>
---
 drivers/scsi/storvsc_drv.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

Comments

Michael Kelley Dec. 6, 2024, 2:58 a.m. UTC | #1
From: mhkelley58@gmail.com <mhkelley58@gmail.com> Sent: Wednesday, October 2, 2024 8:54 PM
> 
> 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>

Martin or James --

This entire series was Acked-by: Peter Zijlstra [1]. Patch 5 of the
series was picked up by the net-next tree a few weeks back and is
in 6.13-rc1. Do you need anything else to pick up this single patch
in the appropriate scsi tree?

I'll separately pursue getting Patches 1 thru 3 of the series
picked up by the Hyper-V tree. There's no interdependency
between the patches in the series, so they can each go
separately.

Michael

[1] https://lore.kernel.org/linux-hyperv/20241004100742.GO18071@noisy.programming.kicks-ass.net/

> ---
>  drivers/scsi/storvsc_drv.c | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 11b3fc3b24c9..f2beb6b23284 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -917,14 +917,13 @@ static int storvsc_channel_init(struct hv_device *device, bool
> is_fc)
> 
>  	/*
>  	 * Allocate state to manage the sub-channels.
> -	 * We allocate an array based on the numbers of possible CPUs
> -	 * (Hyper-V does not support cpu online/offline).
> -	 * This Array will be sparseley populated with unique
> -	 * channels - primary + sub-channels.
> -	 * We will however populate all the slots to evenly distribute
> -	 * the load.
> +	 * We allocate an array based on the number of CPU ids. This array
> +	 * is initially sparsely populated for the CPUs assigned to channels:
> +	 * primary + sub-channels. As I/Os are initiated by different CPUs,
> +	 * the slots for all online CPUs are populated to evenly distribute
> +	 * the load across all channels.
>  	 */
> -	stor_device->stor_chns = kcalloc(num_possible_cpus(), sizeof(void *),
> +	stor_device->stor_chns = kcalloc(nr_cpu_ids, sizeof(void *),
>  					 GFP_KERNEL);
>  	if (stor_device->stor_chns == NULL)
>  		return -ENOMEM;
> --
> 2.25.1
>
Martin K. Petersen Dec. 10, 2024, 2:58 a.m. UTC | #2
Michael,

>> 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.

Applied to 6.14/scsi-staging, thanks!
diff mbox series

Patch

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 11b3fc3b24c9..f2beb6b23284 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -917,14 +917,13 @@  static int storvsc_channel_init(struct hv_device *device, bool is_fc)
 
 	/*
 	 * Allocate state to manage the sub-channels.
-	 * We allocate an array based on the numbers of possible CPUs
-	 * (Hyper-V does not support cpu online/offline).
-	 * This Array will be sparseley populated with unique
-	 * channels - primary + sub-channels.
-	 * We will however populate all the slots to evenly distribute
-	 * the load.
+	 * We allocate an array based on the number of CPU ids. This array
+	 * is initially sparsely populated for the CPUs assigned to channels:
+	 * primary + sub-channels. As I/Os are initiated by different CPUs,
+	 * the slots for all online CPUs are populated to evenly distribute
+	 * the load across all channels.
 	 */
-	stor_device->stor_chns = kcalloc(num_possible_cpus(), sizeof(void *),
+	stor_device->stor_chns = kcalloc(nr_cpu_ids, sizeof(void *),
 					 GFP_KERNEL);
 	if (stor_device->stor_chns == NULL)
 		return -ENOMEM;