All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/ethdev Bug 1887] bnxt: single bad packet in tx burst stalls transmission of remaining valid packets
Date: Thu, 19 Feb 2026 01:26:00 +0000	[thread overview]
Message-ID: <bug-1887-3@http.bugs.dpdk.org/> (raw)

http://bugs.dpdk.org/show_bug.cgi?id=1887

            Bug ID: 1887
           Summary: bnxt: single bad packet in tx burst stalls
                    transmission of remaining valid packets
           Product: DPDK
           Version: 25.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: stephen@networkplumber.org
  Target Milestone: ---

Recent audit of tx_pkt_burst semantics in drivers found this bug.

he bnxt scalar transmit path (`_bnxt_xmit_pkts` in `bnxt_txr.c`) has two
error handling problems that violate the `rte_eth_tx_burst()` contract.

## Bug 1: break-on-error stops processing valid packets

When `bnxt_start_xmit()` returns `-EINVAL` for a malformed packet (bad IOVA,
mismatched `nb_segs`, zero `data_len`, too many TSO segments), the driver
frees the mbuf and increments a drop counter, but then breaks out of the
transmit loop. The dropped packet is correctly included in the return value,
so the immediate caller won't leak or double-free it. However, every valid
packet after the bad one is returned as unconsumed even though there may be
plenty of ring space. The caller must re-submit them in a subsequent call.
In a burst of 32 packets where packet 2 is malformed, 29 valid packets get
needlessly bounced back.

The `break` should be `continue` for the `-EINVAL` case. The `break` is only
appropriate for `-EIO` (device error) and `-ENOMEM` (ring full), where
continuing would be pointless.

```c
/* current code */
if (unlikely(rc)) {
    if (rc == -EINVAL) {
        rte_atomic_fetch_add_explicit(&txq->tx_mbuf_drop, 1,
                                       rte_memory_order_relaxed);
        dropped++;
    }
    break;
}

/* proposed fix */
if (unlikely(rc)) {
    if (rc == -EINVAL) {
        rte_atomic_fetch_add_explicit(&txq->tx_mbuf_drop, 1,
                                       rte_memory_order_relaxed);
        dropped++;
        continue;
    }
    break;
}
```

## Bug 2: partial descriptor ring state on multi-segment drop

`bnxt_start_xmit()` writes transmit descriptors and advances `tx_raw_prod`
incrementally as it walks a multi-segment packet. If validation fails partway
through the segment chain (the zero `data_len` check at line 474), execution
jumps to `drop:` which frees the mbuf but does not roll back `tx_raw_prod` or
clean up the descriptors already written for the earlier segments of that
packet. This leaves orphaned descriptors in the ring that reference a
now-freed mbuf's memory.

This second issue is harder to hit in practice since the failing check
(`data_len == 0` on a middle segment) is unusual, but when it does occur the
consequences — stale DMA addresses in the descriptor ring — are severe.

## Scope

Both bugs are in the scalar path only. The vector paths (`bnxt_xmit_pkts_vec`
and AVX2 variant) skip per-packet validation entirely and are not affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.

                 reply	other threads:[~2026-02-19  1:26 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=bug-1887-3@http.bugs.dpdk.org/ \
    --to=bugzilla@dpdk.org \
    --cc=dev@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.