[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84bf5902-b3e5-4d58-a2a7-f01e15cfe143@gmail.com>
Date: Thu, 9 Oct 2025 16:16:27 +0100
From: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
To: Shuah Khan <skhan@...uxfoundation.org>, akpm@...ux-foundation.org
Cc: linux-kernel@...r.kernel.org, david.hunter.linux@...il.com,
linux-kernel-mentees@...ts.linuxfoundation.org, khalid@...nel.org
Subject: Re: [PATCH] lib: cpu_rmap.c Refactor allocation size calculation in
kzalloc()
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
Powered by blists - more mailing lists