[<prev] [next>] [day] [month] [year] [list]
Message-ID: <75768a26-836d-2aa5-94c8-6d8183745a9c@web.de>
Date: Sun, 3 May 2020 13:30:13 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Qiushi Wu <wu000273@....edu>, netdev@...r.kernel.org,
oss-drivers@...ronome.com
Cc: kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Kangjie Lu <kjlu@....edu>
Subject: Re: [PATCH] nfp: abm: fix a memory leak bug
…
> Fix this issue by adding nfp_nsp_close(nsp) in the error path.
How do you think about a wording variant like the following?
Subject:
[PATCH v2] nfp: abm: Fix incomplete release of system resources in nfp_abm_vnic_set_mac()
Change description:
…
Thus add a call of the function “nfp_nsp_close” for the completion
of the exception handling.
…
> +++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
> @@ -283,6 +283,7 @@ nfp_abm_vnic_set_mac(struct nfp_pf *pf, struct nfp_abm *abm, struct nfp_net *nn,
> if (!nfp_nsp_has_hwinfo_lookup(nsp)) {
> nfp_warn(pf->cpp, "NSP doesn't support PF MAC generation\n");
> eth_hw_addr_random(nn->dp.netdev);
> + nfp_nsp_close(nsp);
> return;
> }
I suggest to reconsider the order for resource clean-up function calls
a bit more.
+ nfp_nsp_close(nsp);
- eth_hw_addr_random(nn->dp.netdev);
- return;
+ goto generate_random_address;
Should such a jump target be added in another update step?
Would you like to add the tag “Fixes”?
Regards,
Markus
Powered by blists - more mailing lists