[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <173583977795.171606.8906239465384373872.b4-ty@oracle.com>
Date: Thu, 2 Jan 2025 17:46:38 -0500
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
decui@...rosoft.com, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, joro@...tes.org, will@...nel.org, robin.murphy@....com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, James.Bottomley@...senPartnership.com,
mhkelley58@...il.com
Cc: "Martin K . Petersen" <martin.petersen@...cle.com>, iommu@...ts.linux.dev,
netdev@...r.kernel.org, linux-hyperv@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: (subset) [PATCH 0/5] hyper-v: Don't assume cpu_possible_mask is dense
On Wed, 02 Oct 2024 20:53:28 -0700, mhkelley58@...il.com wrote:
> 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.
>
> [...]
Applied to 6.14/scsi-queue, thanks!
[4/5] scsi: storvsc: Don't assume cpu_possible_mask is dense
https://git.kernel.org/mkp/scsi/c/6cb7063feb2e
--
Martin K. Petersen Oracle Linux Engineering
Powered by blists - more mailing lists