Re: [PATCH] net/memif: fix descriptor flags corruption in multi-segment TX

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 3 Mar 2026 12:01:52 +0100
Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> 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: stable@dpdk.org
> 
> Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>

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.