From: Thomas Monjalon <thomas@monjalon.net>
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Stojaczyk, Dariusz" <dariusz.stojaczyk@intel.com>
Cc: dev@dpdk.org, "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
"Dariusz Stojaczyk" <darek.stojaczyk@gmail.com>
Subject: Re: [PATCH v2] bus/pci: update device devargs on each rescan
Date: Mon, 12 Nov 2018 01:47:49 +0100 [thread overview]
Message-ID: <1656633.l3hu02U1SK@xps> (raw)
In-Reply-To: <20181106234003.qhimuexm6z4mp7pr@bidouze.vm.6wind.com>
07/11/2018 00:40, Gaëtan Rivet:
> On Tue, Nov 06, 2018 at 10:21:38PM +0000, Zhang, Qi Z wrote:
> > From: Dariusz Stojaczyk [mailto:darek.stojaczyk@gmail.com]
> > > From: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
> > >
> > > Bus rescan is done e.g. during the device hotplug, where devargs are
> > > re-allocated. By not updating the rte_device->devargs pointer we potentially
> > > make it a dangling one, as previous devargs could have been (or will be soon)
> > > freed.
> >
> > Yes, this is the similar issue we met on vdev.
> >
> > The key problem is we have rte_devargs_insert will destroy a devargs which is still referenced by a rte_device
> > I'm thinking , why not just keep always keep a snapshot of devargs in rte_device to make things simple?
> > We could introduce a API like rte_dev_assign_devargs(dev, devargs) which handled the clone and destroy stuff and can be used for all buses.
> > If that idea is acceptable, I would prefer the issue in this patch could be fixed in pci_name_set by clone a new copy as workaround.
> >
>
> I agree that it would be useful to have
>
> rte_devargs_map(devargs, device);
>
> That will link safely a devargs to a device, but cloning is overkill.
>
> I disagree that dangling pointers and loose references is fixed by
> introducing more cloning and copies of stuff here and there.
>
> We must tighten the device -> devargs coupling, not loosen it.
This issue is fixed with a different approach:
http://git.dpdk.org/dpdk/commit/?id=c7ad7754
devargs: do not replace already inserted device
prev parent reply other threads:[~2018-11-12 0:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-05 7:04 [PATCH 1/3] bus/pci: update device devargs on each rescan Darek Stojaczyk
2018-11-05 7:04 ` [PATCH 2/3] devargs: delay freeing previous devargs when overriding them Darek Stojaczyk
2018-11-05 7:30 ` Thomas Monjalon
2018-11-05 8:25 ` Stojaczyk, Dariusz
2018-11-05 9:46 ` Thomas Monjalon
2018-11-05 16:24 ` Gaëtan Rivet
2018-11-05 7:04 ` [PATCH 3/3] eal: handle bus rescan failures during hotplug Darek Stojaczyk
2018-11-05 14:10 ` [PATCH 1/3] bus/pci: update device devargs on each rescan Gaëtan Rivet
2018-11-05 14:52 ` Stojaczyk, Dariusz
2018-11-05 16:27 ` Gaëtan Rivet
2018-11-06 5:40 ` [PATCH v2] " Dariusz Stojaczyk
2018-11-06 22:21 ` Zhang, Qi Z
2018-11-06 23:40 ` Gaëtan Rivet
2018-11-12 0:47 ` Thomas Monjalon [this message]
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=1656633.l3hu02U1SK@xps \
--to=thomas@monjalon.net \
--cc=darek.stojaczyk@gmail.com \
--cc=dariusz.stojaczyk@intel.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=qi.z.zhang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.