linux-kernel - Re: [PATCH 0/5] hyper-v: Don't assume cpu_possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z2HPVCCfznUeMXh3@liuwe-devbox-debian-v2>
Date: Tue, 17 Dec 2024 19:21:56 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Michael Kelley <mhklinux@...look.com>
Cc: "wei.liu@...nel.org" <wei.liu@...nel.org>,
	"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>,
	"kys@...rosoft.com" <kys@...rosoft.com>,
	"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"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>,
	"James.Bottomley@...senPartnership.com" <James.Bottomley@...senpartnership.com>,
	"martin.petersen@...cle.com" <martin.petersen@...cle.com>
Subject: Re: [PATCH 0/5] hyper-v: Don't assume cpu_possible_mask is dense

On Wed, Dec 11, 2024 at 12:14:50AM +0000, Wei Liu wrote:
> On Tue, Dec 10, 2024 at 07:58:34PM +0000, Michael Kelley wrote:
> > From: mhkelley58@...il.com <mhkelley58@...il.com> Sent: Wednesday, October 2, 2024 8:53 PM
> > > 
> > > Code specific to Hyper-V guests currently assumes the cpu_possible_mask
> > > is "dense" -- i.e., all bit positions 0 thru (nr_cpu_ids - 1) are set,
> > > with no "holes". Therefore, num_possible_cpus() is assumed to be equal
> > > to nr_cpu_ids.
> > > 
> > > Per a separate discussion[1], this assumption is not valid in the
> > > general case. For example, the function setup_nr_cpu_ids() in
> > > kernel/smp.c is coded to assume cpu_possible_mask may be sparse,
> > > and other patches have been made in the past to correctly handle
> > > the sparseness. See bc75e99983df1efd ("rcu: Correctly handle sparse
> > > possible cpu") as noted by Mark Rutland.
> > > 
> > > The general case notwithstanding, the configurations that Hyper-V
> > > provides to guest VMs on x86 and ARM64 hardware, in combination
> > > with the algorithms currently used by architecture specific code
> > > to assign Linux CPU numbers, *does* always produce a dense
> > > cpu_possible_mask. So the invalid assumption is not currently
> > > causing failures. But in the interest of correctness, and robustness
> > > against future changes in the code that populates cpu_possible_mask,
> > > update the Hyper-V code to no longer assume denseness.
> > > 
> > > The typical code pattern with the invalid assumption is as follows:
> > > 
> > > 	array = kcalloc(num_possible_cpus(), sizeof(<some struct>),
> > > 			GFP_KERNEL);
> > > 	....
> > > 	index into "array" with smp_processor_id()
> > > 
> > > In such as case, the array might be indexed by a value beyond the size
> > > of the array. The correct approach is to allocate the array with size
> > > "nr_cpu_ids". While this will probably leave unused any 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.
> > > 
> > > Removing the assumption in Hyper-V code is done in several patches
> > > because they touch different kernel subsystems:
> > > 
> > > Patch 1: Hyper-V x86 initialization of hv_vp_assist_page (there's no
> > > 	 hv_vp_assist_page on ARM64)
> > > Patch 2: Hyper-V common init of hv_vp_index
> > > Patch 3: Hyper-V IOMMU driver
> > > Patch 4: storvsc driver
> > > Patch 5: netvsc driver
> > 
> > Wei --
> > 
> > Could you pick up Patches 1, 2, and 3 in this series for the hyperv-next
> > tree? Peter Zijlstra acked the full series [2], and Patches 4 and 5 have
> > already been picked by the SCSI and net maintainers respectively [3][4].
> > 
> > Let me know if you have any concerns.
> 
> Michael, I will take a look later after I finish dealing with the
> hyperv-fixes branch.

Patch 1 to 3 have been applied to the hyperv-next branch.

Wei.