Re: [PATCH] crypto: using size_add() for kmalloc()

[Su Hui <suhui@nfschina.com>]

On 2025/4/21 16:32, Christophe JAILLET wrote:
> Le 21/04/2025 à 09:43, Su Hui a écrit :
>> On 2025/4/21 15:10, Christophe JAILLET wrote:
>>> Le 21/04/2025 à 07:51, Su Hui a écrit :
>>>> It's safer to use size_add() to replace open-coded aithmetic in 
>>>> allocator
>>>> arguments, because size_add() can prevent possible overflow problem.
>>>>
>>>> Signed-off-by: Su Hui <suhui@nfschina.com>
>>>> ---
>>>>   include/crypto/aead.h     | 3 ++-
>>>>   include/crypto/akcipher.h | 4 +++-
>>>>   include/crypto/kpp.h      | 3 ++-
>>>>   3 files changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/include/crypto/aead.h b/include/crypto/aead.h
>>>> index 0e8a41638678..cf212d28fe18 100644
>>>> --- a/include/crypto/aead.h
>>>> +++ b/include/crypto/aead.h
>>>> @@ -10,6 +10,7 @@
>>>>     #include <linux/atomic.h>
>>>>   #include <linux/container_of.h>
>>>> +#include <linux/overflow.h>
>>>
>>> You could move this 1 line below, to keep alphabetical order.
>>> And why do you say that it is redundant in your follow-up mail?
>> Thanks for your suggestion, I didn't notice this alphabetical order 
>> at first :( .
>> Because I found that  <linux/crypto.h> includes <linux/slab.h>, and
>> <linux/slab.h> includes <linux/overflow.h>, so this overflow.h is 
>> redundant.
>
> It is usually considered best practice to include what is used, and 
> not relying on indirect includes.
>
> Should these others includes change one day, then some apparently 
> unrelated files will fails to built.
>
I already send a v2 patch, too fast for this v2 sending :(.
v2: https://lore.kernel.org/all/20250421083116.1161805-1-suhui@nfschina.com/

I agreed with 'include what is used'.  So I guess v1 is enough and v2 
maybe a wrong patchset.
Sorry for the noise.

Su Hui