DPDK patches and discussions
 help / color / mirror / Atom feed
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)
Message-ID: <20190415125045.9eVtTD46acRP-KOmfef2eMj1bKkbySQ4EXEHmgYSUdU@z> (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


  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).