Re: [Intel-wired-lan] [PATCH 1/5] ethtool: use vmalloc_array() to simplify code

[Paul Menzel]

Dear Quianfeng,


Thank you very much for your reply.

Am 14.08.25 um 06:05 schrieb Qianfeng Rong:
> 在 2025/8/13 0:34, Paul Menzel 写道:

[…]

> > Am 12.08.25 um 15:32 schrieb Qianfeng Rong:
> > > Remove array_size() calls and replace vmalloc() with vmalloc_array() to
> > > simplify the code and maintain consistency with existing kmalloc_array()
> > > usage.
> >
> > You could build it without and with your patch and look if the assembler
> > code changes.
>
> Very good point, the following experiment was done:
> //before apply patch:
> objdump -dSl --prefix-addresses fm10k_ethtool.o > original.dis
>
> //after apply patch:
> objdump -dSl --prefix-addresses fm10k_ethtool.o > patched.dis
>
> diff -u original.dis patched.dis | diffstat
> patched.dis | 1578 ... 1 file changed, 785 insertions(+), 793 deletions(-)
>
> From the above results, we can see that the assembly instructions are
> reduced after applying the patch.
>
>
> #define array_size(a, b)    size_mul(a, b)
>
> static inline size_t __must_check size_mul(size_t factor1, size_t factor2)
> {
>      size_t bytes;
>
>      if (check_mul_overflow(factor1, factor2, &bytes))
>          return SIZE_MAX;
>
>      return bytes;
> }
>
> void *__vmalloc_array_noprof(size_t n, size_t size, gfp_t flags)
> {
>      size_t bytes;
>
>      if (unlikely(check_mul_overflow(n, size, &bytes)))
>          return NULL;
>      return __vmalloc_noprof(bytes, flags);
> }
>
> And from the code, array_size() will return SIZE_MAX after detecting
> overflow.  SIZE_MAX is passed to vmalloc for available memory
> verification before exiting and returning NULL. vmalloc_array()
> will directly return NULL after detecting overflow.

Awesome! Thank you for digging that up. Maybe something to add to the 
commit message. Maybe something like:

`vmalloc_array()` is also optimized better, resulting in less 
instructions being used, which can be verified with:

objdump -dSl --prefix-addresses <changed module>.o

> > Reviewed-by: Paul Menzel <pmenzel@xxxxxxxxxxxxx>


Kind regards,

Paul