Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Message-ID: <55b77a28-a680-4465-bb57-2a5cb20ce06a@kylinos.cn>
Date:   Tue, 21 Nov 2023 10:12:17 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH iwl-next] i40e: Use correct buffer size
Content-Language: en-US
To:     Alexander Lobakin <aleksander.lobakin@intel.com>
Cc:     horms@kernel.org, anthony.l.nguyen@intel.com, davem@davemloft.net,
        edumazet@google.com, intel-wired-lan@lists.osuosl.org,
        jeffrey.t.kirsher@intel.com, jesse.brandeburg@intel.com,
        kuba@kernel.org, kunwu.chan@hotmail.com,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        pabeni@redhat.com, shannon.nelson@amd.com
References: <20231113093112.GL705326@kernel.org>
 <20231115031444.33381-1-chentao@kylinos.cn>
 <55e07c56-da57-41aa-bc96-e446fad24276@intel.com>
 <4b551600-f1a3-4efe-b3e9-99cb4536f487@kylinos.cn>
 <2c61c232-1bbb-4cae-bb7f-92a7f2298e97@intel.com>
From:   Kunwu Chan <chentao@kylinos.cn>
In-Reply-To: <2c61c232-1bbb-4cae-bb7f-92a7f2298e97@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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