During the pressure test on the= CX6 using DPDK, the process exits abnormally. It is located that the probl= em is caused by a bug of the DPDK mlx5 driver. Please check whether the lat= est firmware and driver fix this coredump.

By default, the DPDK enables th= e rxtx_vect and compress CQE functions, and the receive ringbuffer is 1024.= During the service process pressure, the service process receives SIGFAULT= and exits.

Call stack information:

#2 0x0= 000000000e72437 in signal_captured_function (signo=3D11, si=3D0x7f6310f46eb= 0, ucontext=3D0x7f6310f46d80) at ../v1/handle_signal.c:499

#3 <= ;signal handler called>

#4 _mm= _storeu_si128 (__B=3D..., __P=3D<optimized out>) at /usr/lib/gcc/x86_= 64-linux-gnu/7.3.0/include/emmintrin.h:720

#5 rxq= _cq_decompress_v (elts=3D0x20217ff394e8, cq=3D0x20217f8538c0, rxq=3D0x20217= ff36e00) at ../drivers/net/mlx5/mlx5_rxtx_vec_sse.h:159=

#6 rxq= _burst_v (no_cq=3D<synthetic pointer>, err=3D<synthetic pointer>= ;, pkts_n=3D9, pkts=3D0x2004e278c9d8, rxq=3D0x20217ff36e00) at ../drivers/n= et/mlx5/mlx5_rxtx_vec.c:349

#7 mlx= 5_rx_burst_vec (dpdk_rxq=3D0x20217ff36e00, pkts=3D0x2004e278c9d8, pkts_n=3D= 128) at ../drivers/net/mlx5/mlx5_rxtx_vec.c:393

#8 0x0= 000000001086448 in rte_eth_rx_burst (nb_pkts=3D128, rx_pkts=3D0x2004e278c9d= 8, queue_id=3D7, port_id=3D<optimized out>) at ../include/dpdk/rte_et= hdev.h:5339

Ethernet controller: Mellanox T= echnologies MT2892 Family [ConnectX-6 Dx]

Version:

[root@localh= ost ~]# ofed_info -s

MLNX_OFED_LI= NUX-23.04-0.5.3.3:

[root@localh= ost ~]# ethtool -i eth6|grep fir

f= irmware-version: 22.37.1014 (MT_0000000359)

dpdk version: DPDK 21.11

../drive= rs/net/mlx5/mlx5_rxtx_vec_sse.h:159

157: &nb= sp; /* B.1 store rearm data to mbuf. */<= /span>

158: &nb= sp; _mm_storeu_si128((__m128i *)&elts[pos += 2]->rearm_data, rearm);

159: &nb= sp; _mm_storeu_si128((__m128i *)&elts[pos += 3]->rearm_data, rearm);

Root cause: When processing com= pressed CQEs, 9 mini CQEs need to be processed and (*rxq->elts)[1021] -&= gt; (*rxq->elts)[1028] is accessed. Only [0, 1027] are reserved during t= he initialization of the receive queue. A null pointer is accessed due to out-of-bounds access. As a result, a core dump = occurs in the process.

(gdb) p elts[0]

$149 =3D (struct rte_mbuf *) 0x= 2006945a8000 //first round

(gdb) p elts[1]

$150 =3D (struct rte_mbuf *) 0x= 2006945aa1c0

(gdb) p elts[2]

$151 =3D (struct rte_mbuf *) 0x= 2006945ac380

(gdb) p elts[3]

$152 =3D (struct rte_mbuf *) 0x= 20217ff36f80

(gdb) p elts[4]

$153 =3D (struct rte_mbuf *) 0x= 20217ff36f80 //Second round

(gdb) p elts[5]

$154 =3D (struct rte_mbuf *) 0x= 20217ff36f80

(gdb) p elts[6]

$155 =3D (struct rte_mbuf *) 0x= 20217ff36f80

(gdb) p elts[7]

$156 =3D (struct rte_mbuf *) 0x= 0 //coredump

(gdb) p elts - (*rxq->elts)<= o:p>

$157 =3D 1021=