From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
wangyunjian <wangyunjian@huawei.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "xudingke@huawei.com" <xudingke@huawei.com>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling i40e_vsi_delete_mac
Date: Mon, 15 Apr 2019 12:50:45 +0000 [thread overview]
Message-ID: <039ED4275CED7440929022BC67E7061153368A95@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772580148A97E3D@irsmsx105.ger.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Monday, April 15, 2019 8:21 PM
> To: wangyunjian <wangyunjian@huawei.com>; dev@dpdk.org
> Cc: xudingke@huawei.com; stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling
> i40e_vsi_delete_mac
>
> Hi,
>
> > Now the macvlan filter list may be accessed in the same time by two
> > different threads and may cause a lot of optional errors. This patch
> > protects the macvlan filter access with a spinlock.
> >
> > Call Trace:
> > #1 0x00007ffb4cbe2e3c in i40e_vsi_delete_mac (vsi=vsi@entry=
> > 0x400052804b40, addr=addr@entry=0x7ffb47672244) at /usr/src/
> > debug/dpdk-18.11/drivers/net/i40e/i40e_ethdev.c:7266
> > #2 0x00007ffb4cbe342b in i40e_set_default_mac_addr (dev=<optimized
> out>,
> > mac_addr=0x400052a6618d) at
> /usr/src/debug/dpdk-18.11/drivers/net/
> > i40e/i40e_ethdev.c:11893
> > #3 0x00007ffb4f569d4a in rte_eth_dev_default_mac_addr_set (port_id=
> > <optimized out>, addr=addr@entry=0x400052a6618d) at
> /usr/src/debug/
> > dpdk-18.11/lib/librte_ethdev/rte_ethdev.c:3366
> > #4 0x00007ffb4d0bb403 in mac_address_slaves_update
> (bonded_eth_dev=
> > bonded_eth_dev@entry=0xacf8c0 <rte_eth_devices>) at
> /usr/src/debug/
> > dpdk-18.11/drivers/net/bonding/rte_eth_bond_pmd.c:1854
> > #5 0x00007ffb4d0bd221 in bond_ethdev_lsc_event_callback (port_id=
> > <optimized out>, type=<optimized out>, param=<optimized out>,
> > ret_param= <optimized out>) at /usr/src/debug/dpdk-18.11/drivers/
> > net/bonding/rte_eth_bond_pmd.c:3076
> > #6 0x00007ffb4f56aa09 in _rte_eth_dev_callback_process
> (dev=dev@entry=
> > 0xad3940 <rte_eth_devices+16512>, event=event@entry=
> > RTE_ETH_EVENT_INTR_LSC, ret_param=ret_param@entry=0x0)
> > at /usr/src/debug/dpdk-18.11/lib/librte_ethdev/rte_ethdev.c:3699
> > #7 0x00007ffb4cbb99f1 in i40e_dev_handle_aq_msg
> (dev=dev@entry=0xad3940
> > <rte_eth_devices+16512>) at
> /usr/src/debug/dpdk-18.11/drivers/net/
> > i40e/i40e_ethdev.c:6573
> > #8 0x00007ffb4cbdfbed in i40e_dev_alarm_handler (param=0xad3940
> > <rte_eth_devices+16512>) at
> /usr/src/debug/dpdk-18.11/drivers/net/
> > i40e/i40e_ethdev.c:6681
> > #9 0x00007ffb4fb9766f in eal_alarm_callback (arg=<optimized out>) at
> >
> /usr/src/debug/dpdk-18.11/lib/librte_eal/linuxapp/eal/eal_alarm.c:90
> > #10 0x00007ffb4fb95dd2 in eal_intr_process_interrupts (nfds=<optimized
> > out>, events=<optimized out>) at /usr/src/debug/dpdk-18.11/lib/
> > librte_eal/linuxapp/eal/eal_interrupts.c:886
> > #11 eal_intr_handle_interrupts (totalfds=<optimized out>, pfd=20) at
> > /usr/src/debug/dpdk-18.11/lib/librte_eal/linuxapp/eal/
> > eal_interrupts.c:946
> > #12 eal_intr_thread_main (arg=<optimized out>) at /usr/src/debug/
> > dpdk-18.11/lib/librte_eal/linuxapp/eal/eal_interrupts.c:1035
> > #13 0x00007ffb4b208dd5 in start_thread () from
> /usr/lib64/libpthread.so.0
> > #14 0x00007ffb4981659d in clone () from /usr/lib64/libc.so.6
>
> That is not specific to i40e or macvlan filter.
> If inside your app several threads concurrently access/modify NIC config, then
> you need to provide some synchronization mechanism for them.
> DPDK ethdev API (as most others) on itself doesn't provide any synchronization,
> leaving it up to the upper layer to choose the most appropriate one.
> Konstantin
+1
next prev parent reply other threads:[~2019-04-15 12:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-13 9:54 wangyunjian
2019-04-13 9:54 ` wangyunjian
2019-04-15 12:21 ` Ananyev, Konstantin
2019-04-15 12:21 ` Ananyev, Konstantin
2019-04-15 12:50 ` Zhang, Qi Z [this message]
2019-04-15 12:50 ` Zhang, Qi Z
2019-04-16 2:05 ` wangyunjian
2019-04-16 2:05 ` wangyunjian
2019-04-23 3:39 ` Zhang, Qi Z
2019-04-23 3:39 ` Zhang, Qi Z
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=039ED4275CED7440929022BC67E7061153368A95@SHSMSX103.ccr.corp.intel.com \
--to=qi.z.zhang@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=stable@dpdk.org \
--cc=wangyunjian@huawei.com \
--cc=xudingke@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).