Messages in this thread | | | Date | Mon, 20 Nov 2023 12:41:51 +0100 | Subject | Re: [PATCH iwl-next] i40e: Use correct buffer size | From | 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
| |