[Bug 990] mlx5 pmd crashing when trying to free mbuf from secondary process when mprq is enabled

[Bug 990] mlx5 pmd crashing when trying to free mbuf from secondary process when mprq is enabled

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=990

            Bug ID: 990
           Summary: mlx5 pmd crashing when trying to free mbuf from
                    secondary process when mprq is enabled
           Product: DPDK
           Version: 21.11
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: sahithi.singam@oracle.com
  Target Milestone: ---

This issue is always reproducible when any two DPDK applications (primary ,
secondary)  are run on mellanox virtual functions using mlx5_pmd with mprq
enabled , segfault occurs whenever the secondary application tries to free a
packet received by primary application. Packet size received should be greater
than 128Bytes to reproduce this issue.  


Run multi process sample application as below on a node with mellanox virtual
functions using mlx5_pmd. 
First start server application as below
1. /opt/dpdk-mp_server  -l 2-3  -n  4 --allow
0000:00:05.0,mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9 --allow 
0000:00:06.0,mprq_en=1,rxqs_min_mprq=1
,mprq_log_stride_num=9 --proc-type=primary   -- -p 0x3 -n 1 

2. Once server is started ,start client application as below 
~ # /opt/dpdk-mp_client    -l 4  -n  4 --proc-type=auto -- -n 0


3. Then from a different machine connected to the above machine, try to send
traffic to the above server/client application using testpmd run as below (note
pktsize should be greater than 128Bytes to reproduce this crash, I am using
256Bytes packets). 

/opt/dpdk-testpmd -l 2-3 -m 4 --allow
0000:00:04.0,mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9  -- --portmask=0x1
--mbcache=64 --forward-mode=txonly 
--eth-peer=0,02:00:17:0A:4B:FB    --stats-period=10  --txpkts=256
--tx-ip=10.1.12.253,10.1.12.27  --txq 1 --rxq 1 


Once the traffic is received by server application, server will receive packets
in mbuf and will send it to client. client will try to free the mbuf during
which it is giving segmentation fault. 

Rootcause for this issue :
=========================
When server tries to receive the packet, mlx5_pmd is internally calling
mprq_buf_to_pkt which will use and attach external buffer to the mbuf (as the
packets from testpmd are greater than 128 bytes size).
When external buffers are used, mlx5_pmd will internally sets the callback
function, which should free this external buffer to the address of
mlx5_mprq_buf_free_cb 
i.e mbuf->shinfo->free_cb will be set to address of mlx5_mprq_buf_free_cb in
primary application (i.e dpdk-mp_server).

But when this mbuf is given to the secondary application i.e dpdk-mp_client ,
while freeing this mbuf, secondary application will try to invoke free_cb in
mbuf but as this address is not mapped correctly in secondary application, it
will give a segmentation fault or could lead to corruption. 

[linux-shell]$ nm   dpdk_build/examples/dpdk-mp_client  |grep -i 
"mlx5_mprq_buf_free_cb"
00000000008886e0 T mlx5_mprq_buf_free_cb
[linux-shell]$ nm   dpdk_build/examples/dpdk-mp_server  |grep -i 
"mlx5_mprq_buf_free_cb"
0000000000888e00 T mlx5_mprq_buf_free_cb

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

[Bug 990] mlx5 pmd crashing when trying to free mbuf from secondary process when mprq is enabled

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=990

Sahithi Singam (sahithi.singam@oracle.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Sahithi Singam (sahithi.singam@oracle.com) ---
Marking this bug as invalid as this is already listed as a limitation in
mellanox nic guide

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