diff options
author | Michael Kelley <mhklinux@outlook.com> | 2024-10-02 20:53:33 -0700 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2024-10-04 13:09:20 -0700 |
commit | c86ab60b92d1f3471a56c8bd0856ca78e705f0f0 (patch) | |
tree | 28ae5a63bf288afcacfee191fe6223aaec2a242a /fs/ecryptfs | |
parent | 5c2ab978f9c90384198000a032d10382f44c3530 (diff) | |
download | linux-c86ab60b92d1f3471a56c8bd0856ca78e705f0f0.tar.gz linux-c86ab60b92d1f3471a56c8bd0856ca78e705f0f0.tar.bz2 linux-c86ab60b92d1f3471a56c8bd0856ca78e705f0f0.zip |
hv_netvsc: Don't assume cpu_possible_mask is dense
Current code allocates the pcpu_sum array with size num_possible_cpus().
This code assumes the 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>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20241003035333.49261-6-mhklinux@outlook.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'fs/ecryptfs')
0 files changed, 0 insertions, 0 deletions