On Tue, 3 Mar 2026 12:01:52 +0100
Sriram Yagnaraman <[email protected]> wrote:
> The memif TX path was using |= to set descriptor flags, which could
> leave stale flag bits from previous ring iterations. This caused
> descriptor corruption when the ring wrapped around, leading to
> malformed packet chains and RX failures.
>
> Initialize d0->flags to 0 before setting MEMIF_DESC_FLAG_NEXT to
> ensure clean descriptor state on each transmission.
>
> Fixes: 43b815d88188 ("net/memif: support zero-copy slave")
> Cc: [email protected]
>
> Signed-off-by: Sriram Yagnaraman <[email protected]>
Looks good, the AI review spotted one thing.
Error: Asymmetric mbuf cleanup between the two Rx paths on truncation
In the first Rx path (fast path, around line 376), the truncation
handler frees mbuf_head and also frees the remaining pre-allocated
mbufs with rte_pktmbuf_free_bulk(mbufs + rx_pkts, MAX_PKT_BURST -
rx_pkts).
In the second Rx path (slow path, around line 469), the
truncation handler frees mbuf_head but does NOT free the remaining
pre-allocated mbufs. If the slow path also pre-allocates mbufs into the
mbufs[] array, this is a resource leak. If the slow path does not
pre-allocate (i.e., allocates one mbuf at a time), then the asymmetry
is correct but should be verified against the full source. Without
seeing the full function, I cannot be 100% certain which case applies.
The existing mbuf == NULL failure path in the fast path (visible in the
context at line 163) also does the rte_pktmbuf_free_bulk cleanup, which
suggests the slow path may handle mbufs differently. Worth confirming
that the slow path does not leak pre-allocated mbufs on this new error
path.
