Use vmalloc_array() instead of vmalloc() to calculate the number of
bytes to allocate.

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 arch/x86/kernel/cpu/sgx/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 9ace84486499..1a59e5956f4b 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -630,7 +630,7 @@ static bool __init sgx_setup_epc_section(u64 phys_addr, u64 size,
 	if (!section->virt_addr)
 		return false;
 
-	section->pages = vmalloc(nr_pages * sizeof(struct sgx_epc_page));
+	section->pages = vmalloc_array(nr_pages, sizeof(struct sgx_epc_page));
 	if (!section->pages) {
 		memunmap(section->virt_addr);
 		return false;
-- 
2.47.0

On 27/10/2024 12:32 am, Thorsten Blum wrote:
> Use vmalloc_array() instead of vmalloc() to calculate the number of
> bytes to allocate.

This says nothing about _why_.  Is it because we want to take advantage 
of the multiplication overflow check inside the vmalloc_array()?

I don't know whether it is implied we should always use vmalloc_array() 
for array allocation like this, i.e., when we see vmalloc() is used for 
array allocation in the kernel we can just write a patch to replace it 
with vmalloc_array() and send to upstream.

I am fine with the code change, though.  So if you can add one more 
sentence to explain why (it's always good to do so), feel free to add:

Acked-by: Kai Huang <kai.huang@intel.com>

> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>   arch/x86/kernel/cpu/sgx/main.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
> index 9ace84486499..1a59e5956f4b 100644
> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -630,7 +630,7 @@ static bool __init sgx_setup_epc_section(u64 phys_addr, u64 size,
>   	if (!section->virt_addr)
>   		return false;
>   
> -	section->pages = vmalloc(nr_pages * sizeof(struct sgx_epc_page));
> +	section->pages = vmalloc_array(nr_pages, sizeof(struct sgx_epc_page));
>   	if (!section->pages) {
>   		memunmap(section->virt_addr);
>   		return false;

On 28. Oct 2024, at 23:29, Huang, Kai wrote:
> On 27/10/2024 12:32 am, Thorsten Blum wrote:
>> Use vmalloc_array() instead of vmalloc() to calculate the number of
>> bytes to allocate.
> 
> This says nothing about _why_.  Is it because we want to take advantage of the multiplication overflow check inside the vmalloc_array()?
> 
> I don't know whether it is implied we should always use vmalloc_array() for array allocation like this, i.e., when we see vmalloc() is used for array allocation in the kernel we can just write a patch to replace it with vmalloc_array() and send to upstream.

It's discouraged to use open-coded arithmetic in allocator arguments:

https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments

Happy to add this, but I assumed it's obvious.

On 29/10/2024 11:47 am, Thorsten Blum wrote:
> On 28. Oct 2024, at 23:29, Huang, Kai wrote:
>> On 27/10/2024 12:32 am, Thorsten Blum wrote:
>>> Use vmalloc_array() instead of vmalloc() to calculate the number of
>>> bytes to allocate.
>>
>> This says nothing about _why_.  Is it because we want to take advantage of the multiplication overflow check inside the vmalloc_array()?
>>
>> I don't know whether it is implied we should always use vmalloc_array() for array allocation like this, i.e., when we see vmalloc() is used for array allocation in the kernel we can just write a patch to replace it with vmalloc_array() and send to upstream.
> 
> It's discouraged to use open-coded arithmetic in allocator arguments:
> 
> https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> 
> Happy to add this, but I assumed it's obvious.

Thanks for the info.