From: Simon Horman <horms@kernel.org>
To: Zhipeng Lu <alexious@zju.edu.cn>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Taku Izumi <izumi.taku@jp.fujitsu.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fjes: fix memleaks in fjes_hw_setup
Date: Mon, 22 Jan 2024 21:05:38 +0000 [thread overview]
Message-ID: <20240122210538.GJ126470@kernel.org> (raw)
In-Reply-To: <20240122172445.3841883-1-alexious@zju.edu.cn>
On Tue, Jan 23, 2024 at 01:24:42AM +0800, Zhipeng Lu wrote:
> In fjes_hw_setup, it allocates several memory and delay the deallocation
> to the fjes_hw_exit in fjes_probe through the following call chain:
>
> fjes_probe
> |-> fjes_hw_init
> |-> fjes_hw_setup
> |-> fjes_hw_exit
>
> However, when fjes_hw_setup fails, fjes_hw_exit won't be called and thus
> all the resources allocated in fjes_hw_setup will be leaked. In this
> patch, we free those resources in fjes_hw_setup and prevents such leaks.
>
> Fixes: 2fcbca687702 ("fjes: platform_driver's .probe and .remove routine")
> Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Hi Zhipeng Lu,
It looks like the last non-trivial change to this driver was in 2016.
So perhaps it is better to leave it be.
But if not, this patch does look correct to me.
Reviewed-by: Simon Horman <horms@kernel.org>
...
> @@ -273,6 +277,25 @@ static int fjes_hw_setup(struct fjes_hw *hw)
> fjes_hw_init_command_registers(hw, ¶m);
>
> return 0;
> +
> +free_epbuf:
> + for (epidx = 0; epidx < hw->max_epid ; epidx++) {
> + if (epidx == hw->my_epid)
> + continue;
> + fjes_hw_free_epbuf(&hw->ep_shm_info[epidx].tx);
> + fjes_hw_free_epbuf(&hw->ep_shm_info[epidx].rx);
> + }
> + fjes_hw_free_shared_status_region(hw);
> +free_res_buf:
> + kfree(hw->hw_info.res_buf);
> + hw->hw_info.res_buf = NULL;
> +free_req_buf:
> + kfree(hw->hw_info.req_buf);
> + hw->hw_info.req_buf = NULL;
> +free_ep_info:
> + kfree(hw->ep_shm_info);
> + hw->ep_shm_info = NULL;
> + return result;
FWIIW, I'm not sure it is necessary to set these pointers NULL,
although it doesn't do any harm.
Also, if this function returns an error,
does the caller (fjes_hw_init()) leak hw->hw_info.trace?
> }
>
> static void fjes_hw_cleanup(struct fjes_hw *hw)
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-01-22 21:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 17:24 [PATCH] fjes: fix memleaks in fjes_hw_setup Zhipeng Lu
2024-01-22 21:05 ` Simon Horman [this message]
2024-01-26 7:27 ` alexious
2024-01-25 5:00 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240122210538.GJ126470@kernel.org \
--to=horms@kernel.org \
--cc=alexious@zju.edu.cn \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.