From: Mingming Cao <mmc@linux.ibm.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch, haren@linux.ibm.com,
ricklind@linux.ibm.com, nnac123@linux.ibm.com,
davemarq@linux.ibm.com, vaishnavi@linux.ibm.com,
bjking1@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
mmc@linux.ibm.com
Subject: [PATCH net-next v1 4/6] ibmvnic: allocate new buffer pools before releasing the old ones
Date: Wed, 5 Aug 2026 15:43:59 -0700 [thread overview]
Message-ID: <20260805224401.58791-5-mmc@linux.ibm.com> (raw)
In-Reply-To: <20260805224401.58791-1-mmc@linux.ibm.com>
An mtu change goes through wait_for_reset() and then init_rx_pools() /
init_tx_pools(). Those helpers release the existing pools before
allocating their replacements:
release_rx_pools(adapter);
adapter->rx_pool = kzalloc_objs(struct ibmvnic_rx_pool, num_pools);
if (!adapter->rx_pool) {
dev_err(dev, "Failed to allocate rx pools\n");
return -ENOMEM;
}
If that allocation fails mid-reset the interface is left with no pools
and stays down after what should have been a refused mtu change, when
it could have kept running with the pools it still had.
Allocate first and only release once the allocation has succeeded. The
tx side has to swap ->tx_pool and ->tso_pool in together, so that
release_tx_pools() never sees one set without the other.
These are small allocations and failing them is unlikely, so this is
about the ordering rather than about any failure seen in the field.
alloc_long_term_buff() has the same shape for a much larger allocation
on the mtu-grow path and is dealt with next.
Fixes: 489de956e7a2 ("ibmvnic: Reuse rx pools when possible")
Fixes: bbd809305bc7 ("ibmvnic: Reuse tx pools when possible")
Reviewed-by: Dave Marquardt <davemarq@linux.ibm.com>
Tested-by: Vaishnavi Bhat <vaishnavi@linux.ibm.com>
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 37 ++++++++++++++++--------------
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index e875f43a1ea1..24c8acc42a93 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1098,6 +1098,7 @@ static int init_rx_pools(struct net_device *netdev)
{
struct ibmvnic_adapter *adapter = netdev_priv(netdev);
struct device *dev = &adapter->vdev->dev;
+ struct ibmvnic_rx_pool *new_rx_pool;
struct ibmvnic_rx_pool *rx_pool;
u64 num_pools;
u64 pool_size; /* # of buffers in one pool */
@@ -1113,15 +1114,16 @@ static int init_rx_pools(struct net_device *netdev)
goto update_ltb;
}
- /* Allocate/populate the pools. */
- release_rx_pools(adapter);
-
- adapter->rx_pool = kzalloc_objs(struct ibmvnic_rx_pool, num_pools);
- if (!adapter->rx_pool) {
+ /* Allocate before release so a failure keeps the old pools. */
+ new_rx_pool = kzalloc_objs(struct ibmvnic_rx_pool, num_pools);
+ if (!new_rx_pool) {
dev_err(dev, "Failed to allocate rx pools\n");
return -ENOMEM;
}
+ release_rx_pools(adapter);
+ adapter->rx_pool = new_rx_pool;
+
/* Set num_active_rx_pools early. If we fail below after partial
* allocation, release_rx_pools() will know how many to look for.
*/
@@ -1333,6 +1335,8 @@ static int init_tx_pools(struct net_device *netdev)
{
struct ibmvnic_adapter *adapter = netdev_priv(netdev);
struct device *dev = &adapter->vdev->dev;
+ struct ibmvnic_tx_pool *new_tso_pool;
+ struct ibmvnic_tx_pool *new_tx_pool;
int num_pools;
u64 pool_size; /* # of buffers in pool */
u64 buff_size;
@@ -1349,26 +1353,25 @@ static int init_tx_pools(struct net_device *netdev)
goto update_ltb;
}
- /* Allocate/populate the pools. */
- release_tx_pools(adapter);
-
+ /* Allocate before release so a failure keeps the old pools. */
pool_size = adapter->req_tx_entries_per_subcrq;
num_pools = adapter->num_active_tx_scrqs;
- adapter->tx_pool = kzalloc_objs(struct ibmvnic_tx_pool, num_pools);
- if (!adapter->tx_pool)
+ new_tx_pool = kzalloc_objs(struct ibmvnic_tx_pool, num_pools);
+ if (!new_tx_pool)
return -ENOMEM;
- adapter->tso_pool = kzalloc_objs(struct ibmvnic_tx_pool, num_pools);
- /* To simplify release_tx_pools() ensure that ->tx_pool and
- * ->tso_pool are either both NULL or both non-NULL.
- */
- if (!adapter->tso_pool) {
- kfree(adapter->tx_pool);
- adapter->tx_pool = NULL;
+ new_tso_pool = kzalloc_objs(struct ibmvnic_tx_pool, num_pools);
+ if (!new_tso_pool) {
+ kfree(new_tx_pool);
return -ENOMEM;
}
+ /* Swap both in together for release_tx_pools(). */
+ release_tx_pools(adapter);
+ adapter->tx_pool = new_tx_pool;
+ adapter->tso_pool = new_tso_pool;
+
/* Set num_active_tx_pools early. If we fail below after partial
* allocation, release_tx_pools() will know how many to look for.
*/
--
2.50.1 (Apple Git-155)
next prev parent reply other threads:[~2026-08-05 22:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 22:43 [PATCH net-next v1 0/6] ibmvnic: honour flexible in-range MTU values Mingming Cao
2026-08-05 22:43 ` [PATCH net-next v1 1/6] ibmvnic: cap rx pool entries against the real buffer size Mingming Cao
2026-08-05 22:43 ` [PATCH net-next v1 2/6] ibmvnic: honour the requested mtu instead of reverting to a fallback Mingming Cao
2026-08-05 22:43 ` [PATCH net-next v1 3/6] ibmvnic: do not unmap long term buffers across a crq reconnect Mingming Cao
2026-08-05 22:43 ` Mingming Cao [this message]
2026-08-05 22:44 ` [PATCH net-next v1 5/6] ibmvnic: allocate a new long term buffer before freeing the old one Mingming Cao
2026-08-05 22:44 ` [PATCH net-next v1 6/6] ibmvnic: change the mtu without a reset where the buffers allow it Mingming Cao
2026-08-06 2:38 ` [PATCH net-next v1 0/6] ibmvnic: honour flexible in-range MTU values Jakub Kicinski
2026-08-06 5:28 ` mingming cao
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=20260805224401.58791-5-mmc@linux.ibm.com \
--to=mmc@linux.ibm.com \
--cc=andrew+netdev@lunn.ch \
--cc=bjking1@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=davemarq@linux.ibm.com \
--cc=edumazet@google.com \
--cc=haren@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=nnac123@linux.ibm.com \
--cc=pabeni@redhat.com \
--cc=ricklind@linux.ibm.com \
--cc=vaishnavi@linux.ibm.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.