[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<BN7PR02MB41487D12B5D5AA07FE7236B6D4312@BN7PR02MB4148.namprd02.prod.outlook.com>
Date: Fri, 6 Dec 2024 02:58:26 +0000
From: Michael Kelley <mhklinux@...look.com>
To: "James.Bottomley@...senPartnership.com"
<James.Bottomley@...senPartnership.com>, "martin.petersen@...cle.com"
<martin.petersen@...cle.com>
CC: "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-hyperv@...r.kernel.org"
<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-scsi@...r.kernel.org"
<linux-scsi@...r.kernel.org>, Michael Kelley <mhklinux@...look.com>,
"kys@...rosoft.com" <kys@...rosoft.com>, "haiyangz@...rosoft.com"
<haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>,
"decui@...rosoft.com" <decui@...rosoft.com>, "tglx@...utronix.de"
<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
<bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"joro@...tes.org" <joro@...tes.org>, "will@...nel.org" <will@...nel.org>,
"robin.murphy@....com" <robin.murphy@....com>, "davem@...emloft.net"
<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>
Subject: RE: [PATCH 4/5] scsi: storvsc: Don't assume cpu_possible_mask is
dense
From: mhkelley58@...il.com <mhkelley58@...il.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@...look.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
>
Powered by blists - more mailing lists