Get duplicate umem desc addr from rx ring when run AF_XDP-example

[Hypoce]

Environment
• OS: Ubuntu 25.04
• Kernel: 6.14.6-061406-generic
• NIC: Mellanox ConnectX-6 Dx
• Driver: mlx5_core 25.10-1.2.2
• Firmware: 22.40.1000 (MT_0000000359)

Description

When running an AF_XDP application, I am getting duplicate UMEM desc.addr values from the RX ring.
This issue does not occur on kernel 5.15 + mlx5. It only appears on kernel 6.14+.

I upgraded to a newer kernel because older versions have known AF_XDP issues (for example:
https://patchew.org/linux/20241122112912.89881-1-larysa.zaremba@intel.com/ ).

To rule out issues in my own program, I tested using the official AF_XDP example:

sudo ./xdpsock -i enp65s0f0np0

The same problem occurs: duplicate desc.addr values appear in the received descriptors.

Relevant code from AF_XDP example (xdpsock.c line 1488)
`
for (i = 0; i < rcvd; i++) {
const struct xdp_desc *desc = xsk_ring_cons__rx_desc(&xsk->rx, idx_rx++);
u64 addr = desc->addr;
u32 len = desc->len;
u64 orig = xsk_umem__extract_addr(addr);
eop_cnt += IS_EOP_DESC(desc->options);

addr = xsk_umem__add_offset_to_addr(addr);
char *pkt = xsk_umem__get_data(xsk->umem->buffer, addr);

hex_dump(pkt, len, addr);
*xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) = orig;

}
`

Even when using the official example without modification, the RX ring returns duplicate descriptor addresses, which should not happen.
This makes it appear that the driver or kernel is re-using UMEM frame addresses without them being returned through the fill queue.

I attempted to read the relevant kernel and driver code to locate the source of the issue, but I could not identify anything obvious, as I am not very familiar with C or kernel internals.

[tohojo]

Hmm, okay, so this sounds like a kernel driver regression? In that case, please report it as such to netdev@vger.kernel.org Cc @magnus-karlsson

[Hypoce]

Thank you. I have some additional information that might help resolve the issue. The problem almost always occurs when the RX PPS is high, and it rarely happens when the PPS is low. The issue occurs regardless of whether I use the kernel’s built-in driver or the mlx5 driver.It not only appears on kernel 6.14+, may be appears on kernel 5.15+,I haven’t tested many kernel versions, so I’m unable to say which versions are affected. but,