From: Jackie Liu <liuyun01@kylinos.cn>

alloc_cpu_rmap() assigns an object index to each possible CPU using
cpu % size. Passing zero therefore triggers a divide error instead of
reporting that the map cannot be allocated.

Reject zero along with sizes that do not fit in the u16 map indices.

Fixes: c39649c331c7 ("lib: cpu_rmap: CPU affinity reverse-mapping")
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
---
 lib/cpu_rmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/cpu_rmap.c b/lib/cpu_rmap.c
index c86ab6e55d17..bbb41d37acb1 100644
--- a/lib/cpu_rmap.c
+++ b/lib/cpu_rmap.c
@@ -28,8 +28,8 @@ struct cpu_rmap *alloc_cpu_rmap(unsigned int size, gfp_t flags)
 	unsigned int cpu;
 	size_t obj_offset;
 
-	/* This is a silly number of objects, and we use u16 indices. */
-	if (size > 0xffff)
+	/* Empty maps are invalid, and we use u16 indices. */
+	if (!size || size > 0xffff)
 		return NULL;
 
 	/* Offset of object pointer array from base structure */
-- 
2.54.0

On Sat, 18 Jul 2026 12:21:55 +0800 Jackie Liu <liu.yun@linux.dev> wrote:

> From: Jackie Liu <liuyun01@kylinos.cn>
> 
> alloc_cpu_rmap() assigns an object index to each possible CPU using
> cpu % size. Passing zero therefore triggers a divide error instead of
> reporting that the map cannot be allocated.

Is there any situation in which this is known to trigger?

> Reject zero along with sizes that do not fit in the u16 map indices.

If passing zero is a caller bug then a divide-by-zero exception is a
fine way of reporting it.  So I'm not seeing a need to make any change
here.

2026年7月18日 12:56, "Andrew Morton" <akpm@linux-foundation.org mailto:akpm@linux-foundation.org?to=%22Andrew%20Morton%22%20%3Cakpm%40linux-foundation.org%3E > 写到:


> 
> On Sat, 18 Jul 2026 12:21:55 +0800 Jackie Liu <liu.yun@linux.dev> wrote:
> 
> > 
> > From: Jackie Liu <liuyun01@kylinos.cn>
> >  
> >  alloc_cpu_rmap() assigns an object index to each possible CPU using
> >  cpu % size. Passing zero therefore triggers a divide error instead of
> >  reporting that the map cannot be allocated.
> > 
> Is there any situation in which this is known to trigger?
> 
> > 
> > Reject zero along with sizes that do not fit in the u16 map indices.
> > 
> If passing zero is a caller bug then a divide-by-zero exception is a
> fine way of reporting it. So I'm not seeing a need to make any change
> here.
>

Thanks. I rechecked all in-tree callers and couldn't find a path which
can legitimately pass zero.  The size is either explicitly checked or
derived from successfully allocated IRQ/RX queue counts, whose minimum
is one.

So zero would indeed indicate a caller bug.  Please disregard this
patch.