[dpdk-dev] [PATCH] eal: fix floating device argument pointer
Gaëtan Rivet
gaetan.rivet at 6wind.com
Wed Oct 24 17:33:45 CEST 2018
On Wed, Oct 24, 2018 at 04:43:45PM +0200, Thomas Monjalon wrote:
> 24/10/2018 00:39, Gaëtan Rivet:
> > Hi,
> >
> > On Mon, Oct 22, 2018 at 09:25:22AM +0200, Thomas Monjalon wrote:
> > > 22/10/2018 07:49, Qi Zhang:
> > > > After we insert a devargs into devargs_list, following bus->scan may
> > > > destroy it due to another rte_devargs_insert. Its better not to use
> > > > a devargs pointer after it has been inserted.
> > >
> >
> > A bus scan calls rte_devargs_insert? Mapping devargs to device is the
> > responsibility of the bus scan, if it calls potentially destructive
> > functions, it must rebuild the map.
> >
> > > I think the problem is in:
> > >
> > > rte_devargs_insert(struct rte_devargs *da)
> > > {
> > > int ret;
> > >
> > > ret = rte_devargs_remove(da);
> > > if (ret < 0)
> > > return ret;
> > > TAILQ_INSERT_TAIL(&devargs_list, da, next);
> > > return 0;
> > > }
> > >
> > > We insert a structure which is freed!
> >
> > Not usually, I hope!
> >
> > >
> > > See http://git.dpdk.org/dpdk/commit/?id=55744d83d525
> > >
> > > Gaetan, what can be the fix?
> >
> > 1. rte_devargs_insert is misdefined.
> > It is designed as a function that can never fail.
> > The function should return void instead.
> >
> > 2. rte_devargs_remove(da), will not remove da itself.
> > It will remove whichever rte_devargs matches da within the internal
> > list. If da does not match any in the list, it does nothing.
> > As da is a newly-callocated structure, it is actually safe to
> > continue using it after having called rte_devargs_remove(), because
> > it cannot possibly have been inserted in the meantime (so would not
> > have been freed, even if another devargs matched it).
>
> If the devargs pointer passed in parameter is the same as the one
> in the list, it will be freed.
>
This would only happen if one did:
rte_devargs_insert(dev->devargs);
> > The actual issue is that the matching rte_devargs within the list
> > would be referenced by a device after a successful scan, meaning that
> > this reference is not safe if someone attemps to insert the same
> > device after the bus->scan(). If my understanding is correct, the above
> > fix is not necessary, but probing should be guarded against
> > re-entrancy.
>
> We may want to probe again with different parameters.
>
Sure, but in this case the fix is to check whether the device is already
probed, and if so remove it before probing it again with the new
devargs.
>
> Nice rant :)
:)
--
Gaëtan Rivet
6WIND
More information about the dev
mailing list