All of 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 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.