From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 816B52BAE for ; Thu, 25 Oct 2018 11:42:26 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id g9-v6so8568920wrq.4 for ; Thu, 25 Oct 2018 02:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=W1z/oBkBWi37d2SlqtFFVmOm/J/WmVbEGrwzEHHmlBk=; b=f7vfTWYErNL5vzH0UVTGAZlredGamlp9I2m3+bVbtKAZ/CA7xBUdK2o1ukPCNYKz9m i8gdB+CeqAQpxVM1HGrG2IjX9AbaUu9Ej2ObzXLlsXcrm6uMX6vFil0zIQCyM2NnjRXf yuK+SleOsou7T28Wo+1J1DR3BEOBQtOAqPKGOTWEDxYIn6euIunx0C+xmoW9yNIL+Jyb +oPn243dHKpbAck/HUWxv9osFOK1GhAMWLjTWrDhIpzYZsdYXUAsb453ifpvSj4GjJCv 0lsQJWTJ0hpfwuxzBGQpIa8BjGWvXVzWUSmcbSRDk28LWEHjj9++1fNUkp/qgWWIo608 5O4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=W1z/oBkBWi37d2SlqtFFVmOm/J/WmVbEGrwzEHHmlBk=; b=tarzmazKxPQc/9ljzFG3SF/1XJZVLeNHmGl+wEQN/zdRqFgdVC00G6FUa5q4jQM5VH ESvcfoyP6qKy5j4cWRciC4CrIP32pS6bX/RRqore3NShNt7xWOSPJm6r2hmF+Uw5HR3C bzfn5q2aOZ3Y2jHGE9q3uGtCBQVTDXwLAzuUor0bmmkk34DKjM84s+PApd+08QSXOWB7 0P4tUauis6YLcrGM9KCFqbIV1dwFb0u72k7MQrT6/iz9iwMRgLj3TDuGojrufrC7YKsg v7k1Tr9A1YexnhnTg/0XlUTG+HZJbRlrOghO4zdOgnjZaF/cs9YGv9BqWS0YILOI203n nO4A== X-Gm-Message-State: AGRZ1gLrKLN3PQFXvTUvAkSzjf886zUt6LK4dlx+jNm+ASi1XJluJ5Sw v/uGK9BOWwdy0N8bUv3FnKO/2g== X-Google-Smtp-Source: AJdET5en3Rs2QNMMTLctwcjV/5vHXyLzWQ4Ok820TBXTqGPPh5xD3ID1EZUMK/R8700erjrxfsfDXg== X-Received: by 2002:adf:e403:: with SMTP id g3-v6mr1061348wrm.96.1540460545727; Thu, 25 Oct 2018 02:42:25 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id p7-v6sm7118466wrt.10.2018.10.25.02.42.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Oct 2018 02:42:24 -0700 (PDT) Date: Thu, 25 Oct 2018 11:42:06 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: "Zhang, Qi Z" Cc: Thomas Monjalon , "dev@dpdk.org" Message-ID: <20181025094206.hcknyw374b6p7f7i@bidouze.vm.6wind.com> References: <20181022054932.39052-1-qi.z.zhang@intel.com> <1576298.HKmtsfqzoT@xps> <20181023223931.kmro2zfyp4c4wbqm@bidouze.vm.6wind.com> <6647495.inI2yHHxz0@xps> <20181024153345.5sdhtitjlqqdrs6c@bidouze.vm.6wind.com> <039ED4275CED7440929022BC67E70611532DB313@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <039ED4275CED7440929022BC67E70611532DB313@SHSMSX103.ccr.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] eal: fix floating device argument pointer X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 09:42:26 -0000 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 > > Cc: dev@dpdk.org; Zhang, Qi Z > > 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