[PATCH net] bnxt_en: Write doorbell when linearizing skb fails

Joe Damato posted 1 patch 1 month ago
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
[PATCH net] bnxt_en: Write doorbell when linearizing skb fails
Posted by Joe Damato 1 month ago
When the driver is handed a burst of packets, the doorbell is deferred
until the end. If the last packet has a huge number of frags, but fails
to linearize, the doorbell will not be written adding latency on TX for
any packets in the ring and holding their DMA mappings until the next
TX. Note that the queue is not stopped, so this issue would delay
pending BDs until the next TX.

This issue was discovered by Sashiko and reading the code verifies that,
while unlikely, it is possible.

Fix this by jumping to tx_free, which replicates the same pre-existing
logic but also writes the doorbell.

Fixes: b91e82129400 ("bnxt_en: Linearize TX SKB if the fragments exceed the max")
Cc: stable@vger.kernel.org
Signed-off-by: Joe Damato <joe@dama.to>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 9c2cc50276a5..d59bcca73a2b 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -502,11 +502,8 @@ static netdev_tx_t bnxt_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (skb_shinfo(skb)->nr_frags > TX_MAX_FRAGS) {
 		netdev_warn_once(dev, "SKB has too many (%d) fragments, max supported is %d.  SKB will be linearized.\n",
 				 skb_shinfo(skb)->nr_frags, TX_MAX_FRAGS);
-		if (skb_linearize(skb)) {
-			dev_kfree_skb_any(skb);
-			dev_core_stats_tx_dropped_inc(dev);
-			return NETDEV_TX_OK;
-		}
+		if (skb_linearize(skb))
+			goto tx_free;
 	}
 #endif
 	if (skb_is_gso(skb) &&

base-commit: dc4b95b8fee95113587e93ca116356032d271371
-- 
2.53.0-Meta
Re: [PATCH net] bnxt_en: Write doorbell when linearizing skb fails
Posted by Michael Chan 1 month ago
On Tue, Aug 25, 2026 at 5:02 PM Joe Damato <joe@dama.to> wrote:
>
> When the driver is handed a burst of packets, the doorbell is deferred
> until the end. If the last packet has a huge number of frags, but fails
> to linearize, the doorbell will not be written adding latency on TX for
> any packets in the ring and holding their DMA mappings until the next
> TX. Note that the queue is not stopped, so this issue would delay
> pending BDs until the next TX.
>
> This issue was discovered by Sashiko and reading the code verifies that,
> while unlikely, it is possible.
>
> Fix this by jumping to tx_free, which replicates the same pre-existing
> logic but also writes the doorbell.
>
> Fixes: b91e82129400 ("bnxt_en: Linearize TX SKB if the fragments exceed the max")
> Cc: stable@vger.kernel.org
> Signed-off-by: Joe Damato <joe@dama.to>

Thanks.
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Re: [PATCH net] bnxt_en: Write doorbell when linearizing skb fails
Posted by Andy Gospodarek 1 month ago
On Wed, Aug 26, 2026 at 2:00 AM Michael Chan <michael.chan@broadcom.com>
wrote:
>
> On Tue, Aug 25, 2026 at 5:02 PM Joe Damato <joe@dama.to> wrote:
> >
> > When the driver is handed a burst of packets, the doorbell is deferred
> > until the end. If the last packet has a huge number of frags, but fails
> > to linearize, the doorbell will not be written adding latency on TX for
> > any packets in the ring and holding their DMA mappings until the next
> > TX. Note that the queue is not stopped, so this issue would delay
> > pending BDs until the next TX.
> >
> > This issue was discovered by Sashiko and reading the code verifies that,
> > while unlikely, it is possible.
> >
> > Fix this by jumping to tx_free, which replicates the same pre-existing
> > logic but also writes the doorbell.
> >
> > Fixes: b91e82129400 ("bnxt_en: Linearize TX SKB if the fragments exceed
the max")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Joe Damato <joe@dama.to>
>
> Thanks.
> Reviewed-by: Michael Chan <michael.chan@broadcom.com>

Looks good to me, too.

Reviewed-by: Andy Gospodarek <gospo@broadcom.com>