Re: [dpdk-dev] [PATCH] eal: fix floating device argument pointer

["Gaëtan Rivet" <gaetan.rivet@6wind.com>]

On Thu, Oct 25, 2018 at 03:22:11AM +0000, Zhang, Qi Z wrote:
> 
> 
> > -----Original Message-----
> > From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com]
> > Sent: Wednesday, October 24, 2018 10:34 AM
> > To: Thomas Monjalon <thomas@monjalon.net>
> > Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>
> > Subject: Re: [dpdk-dev] [PATCH] eal: fix floating device argument pointer
> > 
> > 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.
> 
> This does happens when try to attach a vdev on secondary, and I think this is the real place need to fix.
> I will drop this patch and submit a new fix to prevent unnecessary rte_devargs_insert during the vdev bus scan.
> 

The vdev_init function should call dev_probe instead of reimplementing it.
But looking at the big picture, maybe the real bug is secondary process.

> Thanks
> Qi
> 
> > > >
> > > > > 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

-- 
Gaëtan Rivet
6WIND