| Message ID | 20240626140330.89836-1-urezki@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] mm: vmalloc: Check if a hash-index is in cpu_possible_mask | expand |
On 06/26/24 at 04:03pm, Uladzislau Rezki (Sony) wrote: > The problem is that there are systems where cpu_possible_mask > has gaps between set CPUs, for example SPARC. In this scenario > addr_to_vb_xa() hash function can return an index which accesses > to not-possible and not setup CPU area using per_cpu() macro. > > A per-cpu vmap_block_queue is also used as hash table, incorrectly > assuming the cpu_possible_mask has no gaps. Fix it by adjusting an > index to a next possible CPU. > > v1 -> v2: > - update a commit message. > > Fixes: 062eacf57ad9 ("mm: vmalloc: remove a global vmap_blocks xarray") > Reported-by: Nick Bowler <nbowler@draconx.ca> > Closes: https://lore.kernel.org/linux-kernel/ZntjIE6msJbF8zTa@MiWiFi-R3L-srv/T/ > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > --- > mm/vmalloc.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) LGTM, Reviewed-by: Baoquan He <bhe@redhat.com> > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index b4c42da9f3901..6b783baf12a14 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2544,7 +2544,15 @@ static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); > static struct xarray * > addr_to_vb_xa(unsigned long addr) > { > - int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); > + int index = (addr / VMAP_BLOCK_SIZE) % nr_cpu_ids; > + > + /* > + * Please note, nr_cpu_ids points on a highest set > + * possible bit, i.e. we never invoke cpumask_next() > + * if an index points on it which is nr_cpu_ids - 1. > + */ > + if (!cpu_possible(index)) > + index = cpumask_next(index, cpu_possible_mask); > > return &per_cpu(vmap_block_queue, index).vmap_blocks; > } > -- > 2.39.2 >
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index b4c42da9f3901..6b783baf12a14 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2544,7 +2544,15 @@ static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); static struct xarray * addr_to_vb_xa(unsigned long addr) { - int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); + int index = (addr / VMAP_BLOCK_SIZE) % nr_cpu_ids; + + /* + * Please note, nr_cpu_ids points on a highest set + * possible bit, i.e. we never invoke cpumask_next() + * if an index points on it which is nr_cpu_ids - 1. + */ + if (!cpu_possible(index)) + index = cpumask_next(index, cpu_possible_mask); return &per_cpu(vmap_block_queue, index).vmap_blocks; }
The problem is that there are systems where cpu_possible_mask has gaps between set CPUs, for example SPARC. In this scenario addr_to_vb_xa() hash function can return an index which accesses to not-possible and not setup CPU area using per_cpu() macro. A per-cpu vmap_block_queue is also used as hash table, incorrectly assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index to a next possible CPU. v1 -> v2: - update a commit message. Fixes: 062eacf57ad9 ("mm: vmalloc: remove a global vmap_blocks xarray") Reported-by: Nick Bowler <nbowler@draconx.ca> Closes: https://lore.kernel.org/linux-kernel/ZntjIE6msJbF8zTa@MiWiFi-R3L-srv/T/ Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> --- mm/vmalloc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)