[PATCH] i40e: Use correct buffer size

[PATCH] i40e: Use correct buffer size

[Kunwu Chan]

The size of "i40e_dbg_command_buf" is 256, the size of "name" is
at most 256, plus a null character and the format size,
the total size should be 516.

Fixes: 02e9c290814c ("i40e: debugfs interface")
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
---
 drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index 999c9708def5..d42355fa7217 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -72,7 +72,7 @@ static ssize_t i40e_dbg_command_read(struct file *filp, char __user *buffer,
 {
 	struct i40e_pf *pf = filp->private_data;
 	int bytes_not_copied;
-	int buf_size = 256;
+	int buf_size = 516;
 	char *buf;
 	int len;
 
-- 
2.34.1

Re: [PATCH] i40e: Use correct buffer size

[Simon Horman]

On Sun, Nov 12, 2023 at 07:01:46PM +0800, Kunwu Chan wrote:
> The size of "i40e_dbg_command_buf" is 256, the size of "name" is
> at most 256, plus a null character and the format size,
> the total size should be 516.

Hi Kunwu Chan,

Thanks for your patch.

I'm slightly confused as to why name is at most 256 bytes.
I see that name is IFNAMSIZ = 16 bytes.

In any case, perhaps we could make buf_size dependent on it's
constituent variables, to make things a bit clearer and
a bit more robust.

Something like this (completely untested!):

	int buf_size = IFNAMSIZ + sizeof(i40e_dbg_command_buf) + 4;

Also, I'm not clear if this addresses a problem that can manifest in
practice. Which affects if it it should be treated as a fix for iwl-net
with a fixes tag, or as a feature for iwl-next without a fixes tag.

In either case, if you repost, please designate the target tree in the
Subject line. Something like this:

	Subject: [PATCH iwl-next] ...

Lastly, when reposting patches, please allow 24h to elapse since
the previous posting.

Link: https://docs.kernel.org/process/maintainer-netdev.html

...

Re: [PATCH] i40e: Use correct buffer size

[Kunwu Chan]

Hi Simon,
Thank you very much for taking the valuable time to point out my 
problems and shortcomings in detail.
It's my  bad.I misinterpreted 'IFALIASZ' in 'include/uapi/linux/if.h' as 
'IFNAMSIZ'. This led me to think that 'IFNAMSIZ' could be up to 256. 
Sorry again for the trouble.
Yes, it is good code to dynamically calculate the size of the parts that 
make up the 'buffer' and add them up to the size of the whole 'buffer', 
I got lazy because I saw that the other parts had a lot of fixed 'buffer 
size'. I will immediately modify the patch according to your detailed 
suggestions.
 From the code analysis, this place should have a 'snprintf truncation' 
problem, but the impact may not be very big, I found the potential 
problem during the compilation process, after changing the buffer size, 
recompilation will not alarm.
I'll follow your detailed suggestions and remove the 'Fixes' tag and add 
'iwl-next' to the subject.
Thank you again for your reply and guidance.

在 2023/11/13 17:31, Simon Horman 写道:
> [PATCH iwl-next]

[PATCH iwl-next] i40e: Use correct buffer size

[Kunwu Chan]

The size of "i40e_dbg_command_buf" is 256, the size of "name"
depends on "IFNAMSIZ", plus a null character and format size,
the total size is more than 256, fix it.

Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Suggested-by: Simon Horman <horms@kernel.org>
---
 drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index 999c9708def5..e3b939c67cfe 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -72,7 +72,7 @@ static ssize_t i40e_dbg_command_read(struct file *filp, char __user *buffer,
 {
 	struct i40e_pf *pf = filp->private_data;
 	int bytes_not_copied;
-	int buf_size = 256;
+	int buf_size = IFNAMSIZ + sizeof(i40e_dbg_command_buf) + 4;
 	char *buf;
 	int len;
 
-- 
2.34.1

Re: [PATCH iwl-next] i40e: Use correct buffer size

[Simon Horman]

On Wed, Nov 15, 2023 at 11:14:44AM +0800, Kunwu Chan wrote:
> The size of "i40e_dbg_command_buf" is 256, the size of "name"
> depends on "IFNAMSIZ", plus a null character and format size,
> the total size is more than 256, fix it.
> 
> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
> Suggested-by: Simon Horman <horms@kernel.org>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks for the update.

There is no need to repost because of this, but in future please keep in
mind that revised patches should:

1. have a revision number, e.g. v2

   Subject [PATCH v2 iwl-next] ...

2. Have some of revision information below the scissors (---)

   v2
   - Updated size calculation to use IFNAMSIZ and izeof(i40e_dbg_command_buf)

3. Be a new thread, as opposed to a reply to an existing thread.

Link: https://docs.kernel.org/process/maintainer-netdev.html#changes-requested

The above notwithstanding, this patch looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH iwl-next] i40e: Use correct buffer size

[Alexander Lobakin]

From: Kunwu Chan <chentao@kylinos.cn>
Date: Wed, 15 Nov 2023 11:14:44 +0800

> The size of "i40e_dbg_command_buf" is 256, the size of "name"
> depends on "IFNAMSIZ", plus a null character and format size,
> the total size is more than 256, fix it.
> 
> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
> Suggested-by: Simon Horman <horms@kernel.org>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> index 999c9708def5..e3b939c67cfe 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
> @@ -72,7 +72,7 @@ static ssize_t i40e_dbg_command_read(struct file *filp, char __user *buffer,
>  {
>  	struct i40e_pf *pf = filp->private_data;
>  	int bytes_not_copied;
> -	int buf_size = 256;
> +	int buf_size = IFNAMSIZ + sizeof(i40e_dbg_command_buf) + 4;

Reverse Christmas Tree style? Should be the first one in the declaration
list.

>  	char *buf;
>  	int len;

You can fix it in a different way. Given that there's a kzalloc() either
way, why not allocate the precise required amount of bytes by using
kasprintf() instead of kzalloc() + snprintf()? You wouldn't need to
calculate any buffer sizes etc. this way.

Thanks,
Olek

Re: [PATCH iwl-next] i40e: Use correct buffer size

[Kunwu Chan]

Hi Alexander,
Thank you so much for your reply, I looked at the modification you 
mentioned, it's really cool. I'll definitely try it next time.

But when using it, will it be easy to forget to free up memory?
Although 'kmalloc_track_caller' is used, according to my understanding, 
it is also necessary to release the memory at the end of use.

On 2023/11/15 23:39, Alexander Lobakin wrote:
> From: Kunwu Chan <chentao@kylinos.cn>
> Date: Wed, 15 Nov 2023 11:14:44 +0800
> 
>> The size of "i40e_dbg_command_buf" is 256, the size of "name"
>> depends on "IFNAMSIZ", plus a null character and format size,
>> the total size is more than 256, fix it.
>>
>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
>> Suggested-by: Simon Horman <horms@kernel.org>
>> ---
>>   drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>> index 999c9708def5..e3b939c67cfe 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>> @@ -72,7 +72,7 @@ static ssize_t i40e_dbg_command_read(struct file *filp, char __user *buffer,
>>   {
>>   	struct i40e_pf *pf = filp->private_data;
>>   	int bytes_not_copied;
>> -	int buf_size = 256;
>> +	int buf_size = IFNAMSIZ + sizeof(i40e_dbg_command_buf) + 4;
> 
> Reverse Christmas Tree style? Should be the first one in the declaration
> list.
> 
>>   	char *buf;
>>   	int len;
> 
> You can fix it in a different way. Given that there's a kzalloc() either
> way, why not allocate the precise required amount of bytes by using
> kasprintf() instead of kzalloc() + snprintf()? You wouldn't need to
> calculate any buffer sizes etc. this way.
> 
> Thanks,
> Olek

Re: [PATCH iwl-next] i40e: Use correct buffer size

[Alexander Lobakin]

From: Kunwu Chan <chentao@kylinos.cn>
Date: Sun, 19 Nov 2023 23:12:09 +0800

> Hi Alexander,
> Thank you so much for your reply, I looked at the modification you
> mentioned, it's really cool. I'll definitely try it next time.
> 
> But when using it, will it be easy to forget to free up memory?

You have a kfree() at the end of the function.

Generally speaking, 'ka' stands for "[kernel] allocate" and you also
need to pass GPF_ as the second argument. Enough hints that you need to
free the pointer after using it I would say.

> Although 'kmalloc_track_caller' is used, according to my understanding,
> it is also necessary to release the memory at the end of use.
> 
> On 2023/11/15 23:39, Alexander Lobakin wrote:
>> From: Kunwu Chan <chentao@kylinos.cn>
>> Date: Wed, 15 Nov 2023 11:14:44 +0800
>>
>>> The size of "i40e_dbg_command_buf" is 256, the size of "name"
>>> depends on "IFNAMSIZ", plus a null character and format size,
>>> the total size is more than 256, fix it.
>>>
>>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
>>> Suggested-by: Simon Horman <horms@kernel.org>
>>> ---
>>>   drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>> b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>> index 999c9708def5..e3b939c67cfe 100644
>>> --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>> @@ -72,7 +72,7 @@ static ssize_t i40e_dbg_command_read(struct file
>>> *filp, char __user *buffer,
>>>   {
>>>       struct i40e_pf *pf = filp->private_data;
>>>       int bytes_not_copied;
>>> -    int buf_size = 256;
>>> +    int buf_size = IFNAMSIZ + sizeof(i40e_dbg_command_buf) + 4;
>>
>> Reverse Christmas Tree style? Should be the first one in the declaration
>> list.
>>
>>>       char *buf;
>>>       int len;
>>
>> You can fix it in a different way. Given that there's a kzalloc() either
>> way, why not allocate the precise required amount of bytes by using
>> kasprintf() instead of kzalloc() + snprintf()? You wouldn't need to
>> calculate any buffer sizes etc. this way.
>>
>> Thanks,
>> Olek

Thanks,
Olek

Re: [PATCH iwl-next] i40e: Use correct buffer size

[Kunwu Chan]

Thanks for your reply. I understand what you mean, i.e. the caller of 
'kasprintf' is responsible for calling 'kfree' to free up memory.

My concern is that in many scenarios, the requested memory will be 
released after a period of use.

Has anyone else forgotten to free up the requested memory when using 
'kasprintf'? e.g. 'dam_heap_init' calls 'dma_heap_devnode' to allocate 
memory:
dam_heap_init
	-> dma_heap_devnode
		  -> kasprintf
			->kvasprintf
			     ->kmalloc_node_track_caller
			  	-> __kmalloc_node_track_caller
					  -> __do_kmalloc_node
						  -> kasan_kmalloc


There is no function like 'dam_heap_exit' to free the memmory allocated 
by dma_heap_devnode.

Another case is 'cpuid_devnode'. Will this cause a memory leak, and is 
there a better way to avoid the memory leak in this case?

Or is there a uniform place in the memory management module to free up 
this memory?

Thanks,
Kunwu

On 2023/11/20 19:41, Alexander Lobakin wrote:
> From: Kunwu Chan <chentao@kylinos.cn>
> Date: Sun, 19 Nov 2023 23:12:09 +0800
> 
>> Hi Alexander,
>> Thank you so much for your reply, I looked at the modification you
>> mentioned, it's really cool. I'll definitely try it next time.
>>
>> But when using it, will it be easy to forget to free up memory?
> 
> You have a kfree() at the end of the function.
> 
> Generally speaking, 'ka' stands for "[kernel] allocate" and you also
> need to pass GPF_ as the second argument. Enough hints that you need to
> free the pointer after using it I would say.
> 
>> Although 'kmalloc_track_caller' is used, according to my understanding,
>> it is also necessary to release the memory at the end of use.
>>
>> On 2023/11/15 23:39, Alexander Lobakin wrote:
>>> From: Kunwu Chan <chentao@kylinos.cn>
>>> Date: Wed, 15 Nov 2023 11:14:44 +0800
>>>
>>>> The size of "i40e_dbg_command_buf" is 256, the size of "name"
>>>> depends on "IFNAMSIZ", plus a null character and format size,
>>>> the total size is more than 256, fix it.
>>>>
>>>> Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
>>>> Suggested-by: Simon Horman <horms@kernel.org>
>>>> ---
>>>>    drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>>> b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>>> index 999c9708def5..e3b939c67cfe 100644
>>>> --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>>>> @@ -72,7 +72,7 @@ static ssize_t i40e_dbg_command_read(struct file
>>>> *filp, char __user *buffer,
>>>>    {
>>>>        struct i40e_pf *pf = filp->private_data;
>>>>        int bytes_not_copied;
>>>> -    int buf_size = 256;
>>>> +    int buf_size = IFNAMSIZ + sizeof(i40e_dbg_command_buf) + 4;
>>>
>>> Reverse Christmas Tree style? Should be the first one in the declaration
>>> list.
>>>
>>>>        char *buf;
>>>>        int len;
>>>
>>> You can fix it in a different way. Given that there's a kzalloc() either
>>> way, why not allocate the precise required amount of bytes by using
>>> kasprintf() instead of kzalloc() + snprintf()? You wouldn't need to
>>> calculate any buffer sizes etc. this way.
>>>
>>> Thanks,
>>> Olek
> 
> Thanks,
> Olek

Re: [PATCH iwl-next] i40e: Use correct buffer size

[Alexander Lobakin]

From: Kunwu Chan <chentao@kylinos.cn>
Date: Tue, 21 Nov 2023 10:12:17 +0800

> Thanks for your reply. I understand what you mean, i.e. the caller of
> 'kasprintf' is responsible for calling 'kfree' to free up memory.
> 
> My concern is that in many scenarios, the requested memory will be
> released after a period of use.
> 
> Has anyone else forgotten to free up the requested memory when using
> 'kasprintf'? e.g. 'dam_heap_init' calls 'dma_heap_devnode' to allocate
> memory:
> dam_heap_init
>     -> dma_heap_devnode
>           -> kasprintf
>             ->kvasprintf
>                  ->kmalloc_node_track_caller
>                   -> __kmalloc_node_track_caller
>                       -> __do_kmalloc_node
>                           -> kasan_kmalloc
> 
> 
> There is no function like 'dam_heap_exit' to free the memmory allocated
> by dma_heap_devnode.
> 
> Another case is 'cpuid_devnode'. Will this cause a memory leak, and is
> there a better way to avoid the memory leak in this case?
> 
> Or is there a uniform place in the memory management module to free up
> this memory?

If the lifetime of the allocated buffer equals to the lifetime of the
kernel, i.e. it's allocated once at kernel init and then used throughout
the whole uptime, there's no need to free this piece.
Temporary buffers or buffers allocated from a driver are a different
story, their lifetime is shorter, which means you always need to
manually free each of them on exit.

> 
> Thanks,
> Kunwu
Thanks,
Olek

Re: [PATCH iwl-next] i40e: Use correct buffer size

[Kunwu Chan]

Thanks you again for your reply.
I learned. I know how to use it, thanks, I'll look at the existing code 
and add logs to see how it works.

Thanks again.


On 2023/11/21 19:15, Alexander Lobakin wrote:
> From: Kunwu Chan <chentao@kylinos.cn>
> Date: Tue, 21 Nov 2023 10:12:17 +0800
> 
>> Thanks for your reply. I understand what you mean, i.e. the caller of
>> 'kasprintf' is responsible for calling 'kfree' to free up memory.
>>
>> My concern is that in many scenarios, the requested memory will be
>> released after a period of use.
>>
>> Has anyone else forgotten to free up the requested memory when using
>> 'kasprintf'? e.g. 'dam_heap_init' calls 'dma_heap_devnode' to allocate
>> memory:
>> dam_heap_init
>>      -> dma_heap_devnode
>>            -> kasprintf
>>              ->kvasprintf
>>                   ->kmalloc_node_track_caller
>>                    -> __kmalloc_node_track_caller
>>                        -> __do_kmalloc_node
>>                            -> kasan_kmalloc
>>
>>
>> There is no function like 'dam_heap_exit' to free the memmory allocated
>> by dma_heap_devnode.
>>
>> Another case is 'cpuid_devnode'. Will this cause a memory leak, and is
>> there a better way to avoid the memory leak in this case?
>>
>> Or is there a uniform place in the memory management module to free up
>> this memory?
> 
> If the lifetime of the allocated buffer equals to the lifetime of the
> kernel, i.e. it's allocated once at kernel init and then used throughout
> the whole uptime, there's no need to free this piece.
> Temporary buffers or buffers allocated from a driver are a different
> story, their lifetime is shorter, which means you always need to
> manually free each of them on exit.
> 
>>
>> Thanks,
>> Kunwu
> Thanks,
> Olek