Re: [PATCH] lib: cpu_rmap.c Refactor allocation size calculation in kzalloc()

[Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>]

On 10/7/25 11:23 PM, Shuah Khan wrote:

> 
> How did you find this problem and how did you test this change?
For the first part of your question,After simply referring to deprecated 
documentation[1] which states the following:
'For other calculations, please compose the use of the size_mul(), 
size_add(), and size_sub() helpers'
Which is about dynamic calculations made inside of kzalloc() and 
kmalloc(). Specifically, the quoted part is talking about calculations 
which can't be simply divided into two parameters referring to the 
number of elements and size per element and in cases where we can't use 
struct_size() too.After that it was a matter of finding code where that 
could be the problem which is the case of the changed code.

For the second part, As per any patch,I make a copy of all dmesg 
warnings errors critical messages,then I compile install and boot the 
new kernel then check if there is any change or regression in dmesg.
For this particular change, since it doesn't have any selftests because 
it's in utility library which in my case cpu_rmap is used in the 
networking subsystem, I did some fault injection with a custom module to 
test if in case of overflow it fails safely reporting the issue in dmesg 
which is catched by the __alloc_frozen_pages_noprof() function in 
mm/page_alloc.c and also return a NULL for rmap instead of wrapping to a 
smaller size.

If any further testing or work to be done or even suggestions on 
improvements to my testing methodology, I would gladly hear any advice.
Thank you for you time.

> 
> thanks,
> -- Shuah

Best Regards,
Mehdi Ben Hadj Khelifa