| Message ID | 20231115031444.33381-1-chentao@kylinos.cn (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [iwl-next] i40e: Use correct buffer size | expand |
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>
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
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
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
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
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
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
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;
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(-)