From: Kunwu Chan <[email protected]>
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 <[email protected]>
> Suggested-by: Simon Horman <[email protected]>
> ---
> 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
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 <[email protected]>
> 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 <[email protected]>
>> Suggested-by: Simon Horman <[email protected]>
>> ---
>> 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
From: Kunwu Chan <[email protected]>
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 <[email protected]>
>> 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 <[email protected]>
>>> Suggested-by: Simon Horman <[email protected]>
>>> ---
>>> 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
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 <[email protected]>
> 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 <[email protected]>
>>> 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 <[email protected]>
>>>> Suggested-by: Simon Horman <[email protected]>
>>>> ---
>>>> 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
From: Kunwu Chan <[email protected]>
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
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 <[email protected]>
> 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