DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	stable@dpdk.org, Selwin Sebastian <selwin.sebastian@amd.com>,
	Chandubabu Namburu <chandu@amd.com>,
	Ravi Kumar <ravi1.kumar@amd.com>
Subject: [PATCH v3 1/4] net/axgbe: fix resource leaks in device init error paths
Date: Thu, 18 Jun 2026 10:21:56 -0700	[thread overview]
Message-ID: <20260618172544.338758-2-stephen@networkplumber.org> (raw)
In-Reply-To: <20260618172544.338758-1-stephen@networkplumber.org>

Several error paths in eth_axgbe_dev_init() fail to release
previously allocated resources:

 - When hash_mac_addrs allocation fails, mac_addrs is leaked.
 - When phy_init() fails, hash_mac_addrs is leaked.
 - When phy_init() or the interrupt registration fails, the four
   mutexes initialized just before phy_init() are leaked.
 - The return value of rte_intr_callback_register() is not
   checked, so a failure leaves the driver without interrupt
   handling but continuing as if everything is functional.
 - When the DMA software reset via hw_if.exit() fails, the
   error is only logged and initialization continues with the
   hardware in an undefined state.

Replace the scattered cleanups with a single goto unwind so each
error path releases exactly the resources allocated up to that
point: the hw_if.exit() failure runs before the mutexes are
initialized and so skips the mutex teardown, while the phy_init()
and interrupt-registration failures destroy the mutexes as well.
Also check the interrupt registration return value and propagate
the DMA reset failure.

Fixes: e01d9b2e980b ("net/axgbe: support unicast hash table for MAC address")
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/net/axgbe/axgbe_ethdev.c | 35 +++++++++++++++++++++++---------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/net/axgbe/axgbe_ethdev.c b/drivers/net/axgbe/axgbe_ethdev.c
index 61725d55ca..415fc6d739 100644
--- a/drivers/net/axgbe/axgbe_ethdev.c
+++ b/drivers/net/axgbe/axgbe_ethdev.c
@@ -2360,7 +2360,8 @@ eth_axgbe_dev_init(struct rte_eth_dev *eth_dev)
 		PMD_INIT_LOG(ERR,
 			     "Failed to allocate %d bytes needed to "
 			     "store MAC addresses", len);
-		return -ENOMEM;
+		ret = -ENOMEM;
+		goto err_mac;
 	}
 
 	if (!rte_is_valid_assigned_ether_addr(&pdata->mac_addr))
@@ -2406,8 +2407,10 @@ eth_axgbe_dev_init(struct rte_eth_dev *eth_dev)
 					  pdata->vdata->rx_max_fifo_size);
 	/* Issue software reset to DMA */
 	ret = pdata->hw_if.exit(pdata);
-	if (ret)
+	if (ret) {
 		PMD_DRV_LOG_LINE(ERR, "hw_if->exit EBUSY error");
+		goto err_hash;
+	}
 
 	/* Set default configuration data */
 	axgbe_default_config(pdata);
@@ -2426,20 +2429,32 @@ eth_axgbe_dev_init(struct rte_eth_dev *eth_dev)
 	rte_thread_mutex_init_shared(&pdata->phy_mutex);
 
 	ret = pdata->phy_if.phy_init(pdata);
-	if (ret) {
-		rte_free(eth_dev->data->mac_addrs);
-		eth_dev->data->mac_addrs = NULL;
-		return ret;
-	}
+	if (ret)
+		goto err_mutex;
 
-	rte_intr_callback_register(pci_dev->intr_handle,
-				   axgbe_dev_interrupt_handler,
-				   (void *)eth_dev);
+	ret = rte_intr_callback_register(pci_dev->intr_handle,
+					 axgbe_dev_interrupt_handler,
+					 (void *)eth_dev);
+	if (ret)
+		goto err_mutex;
 	PMD_INIT_LOG(DEBUG, "port %d vendorID=0x%x deviceID=0x%x",
 		     eth_dev->data->port_id, pci_dev->id.vendor_id,
 		     pci_dev->id.device_id);
 
 	return 0;
+
+err_mutex:
+	pthread_mutex_destroy(&pdata->phy_mutex);
+	pthread_mutex_destroy(&pdata->an_mutex);
+	pthread_mutex_destroy(&pdata->i2c_mutex);
+	pthread_mutex_destroy(&pdata->xpcs_mutex);
+err_hash:
+	rte_free(eth_dev->data->hash_mac_addrs);
+	eth_dev->data->hash_mac_addrs = NULL;
+err_mac:
+	rte_free(eth_dev->data->mac_addrs);
+	eth_dev->data->mac_addrs = NULL;
+	return ret;
 }
 
 static int
-- 
2.53.0


  reply	other threads:[~2026-06-18 17:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18 16:40 [PATCH 0/4] net/axgbe: fix resource leaks and OOB access Stephen Hemminger
2026-02-18 16:40 ` [PATCH 1/4] net/axgbe: fix resource leaks in device init error paths Stephen Hemminger
2026-02-18 16:41 ` [PATCH 2/4] net/axgbe: fix Rx queue leak on descriptor init failure Stephen Hemminger
2026-04-05 16:11   ` Stephen Hemminger
2026-02-18 16:41 ` [PATCH 3/4] net/axgbe: destroy mutexes on device close Stephen Hemminger
2026-02-18 16:41 ` [PATCH 4/4] net/axgbe: fix descriptor status out-of-bounds access Stephen Hemminger
2026-02-20 17:50 ` [PATCH 0/4] net/axgbe: fix resource leaks and OOB access Stephen Hemminger
2026-02-25 16:52 ` Stephen Hemminger
2026-02-26 12:43   ` Sebastian, Selwin
2026-03-06 18:55 ` Stephen Hemminger
2026-03-08 16:53   ` Ande, Venkat Kumar
2026-03-11 10:53   ` Sebastian, Selwin
2026-05-08 19:10 ` [PATCH v2 " Stephen Hemminger
2026-05-08 19:10   ` [PATCH v2 1/4] net/axgbe: fix resource leaks in device init error paths Stephen Hemminger
2026-05-08 19:10   ` [PATCH v2 2/4] net/axgbe: fix Rx queue leak on descriptor init failure Stephen Hemminger
2026-05-08 19:10   ` [PATCH v2 3/4] net/axgbe: destroy mutexes on device close Stephen Hemminger
2026-05-08 19:10   ` [PATCH v2 4/4] net/axgbe: fix descriptor status out-of-bounds access Stephen Hemminger
2026-06-18 17:21 ` [PATCH v3 0/4] net/axgbe: fix resource leaks and OOB access Stephen Hemminger
2026-06-18 17:21   ` Stephen Hemminger [this message]
2026-06-18 17:21   ` [PATCH v3 2/4] net/axgbe: fix Rx queue leak on descriptor init failure Stephen Hemminger
2026-06-18 17:21   ` [PATCH v3 3/4] net/axgbe: destroy mutexes on device close Stephen Hemminger
2026-06-18 17:21   ` [PATCH v3 4/4] net/axgbe: fix descriptor status out-of-bounds access Stephen Hemminger

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=20260618172544.338758-2-stephen@networkplumber.org \
    --to=stephen@networkplumber.org \
    --cc=chandu@amd.com \
    --cc=dev@dpdk.org \
    --cc=ravi1.kumar@amd.com \
    --cc=selwin.sebastian@amd.com \
    --cc=stable@dpdk.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox