[Bug 1234] iavf : crash observed during rte_eth_dev_stop

[bugzilla at dpdk.org]

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

            Bug ID: 1234
           Summary: iavf : crash observed during rte_eth_dev_stop
           Product: DPDK
           Version: 21.11
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: ethdev
          Assignee: dev at dpdk.org
          Reporter: sahithi.singam at oracle.com
  Target Milestone: ---

We are using DPDK in our application which has two processes , first one will
be a primary DPDK process where as second one will be a secondary DPDK process. 
While our primary process calls all dpdk initialization routines like
rte_eal_init, dev_configure, rx/tx queue setup and dev_start routines, our
secondary process will invoke just rte_eal_init. 

In DPDK, rte_eth_dev->data->rx_queues and rte_eth_dev->data->tx_queues is a
shared data structure between both primary and secondary processes.  

In iavf pmd, each rxq(i.e above rx_queues) and txq (above tx_queues) holds a
pointer to the function ( eg. in rx_queues[index]->ops->release_mbufs) which
will be invoked during rte_eth_dev_stop. 

Call to iavf_set_rx_function modifies this function pointer i.e release_mbufs. 

This function pointer will be initially set to a address by primary process ->
rte_eth_dev_start() -> iavf_init_queues() -> iavf_set_rx_function().

Later this function pointer is updated by secondary process to its own address
-> 
rte_eal_init()) -> iavf_dev_init() -> iavf_set_rx_function() . This address
will be invalid in primary process address space. 

During application shutdown, we are invoking rte_eth_dev_stop from primary
process which invokes release_mbufs function . As the address stored in
release_mbufs function pointer now points to an invalid address , primary
process is crashing always.

Note:
This bug will also be observed in other PMDs like ice, ixgbe which uses similar
code/design.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20230519/ac8a1a4d/attachment.htm>