From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id F0C672BAE for ; Thu, 25 Oct 2018 05:22:15 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 20:22:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,422,1534834800"; d="scan'208";a="102459378" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga001.jf.intel.com with ESMTP; 24 Oct 2018 20:22:14 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 24 Oct 2018 20:22:14 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 24 Oct 2018 20:22:13 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.161]) by shsmsx102.ccr.corp.intel.com ([169.254.2.84]) with mapi id 14.03.0415.000; Thu, 25 Oct 2018 11:22:11 +0800 From: "Zhang, Qi Z" To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= , Thomas Monjalon CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] eal: fix floating device argument pointer Thread-Index: AQHUacsIrccfeUQm/ka4MkmRBpMmwKUqVxYAgAKRvoCAAQ1ngIAADfmAgAFLJ8A= Date: Thu, 25 Oct 2018 03:22:11 +0000 Message-ID: <039ED4275CED7440929022BC67E70611532DB313@SHSMSX103.ccr.corp.intel.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> In-Reply-To: <20181024153345.5sdhtitjlqqdrs6c@bidouze.vm.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjQyOTAxZTItOTM5Yi00MGM4LTg5MzEtMGIzNTMwOWY5YmM2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYXJRSWY1ZFlJaThkRmdyQUkrQVZXTjZGV0tQRHVtZW9HSVQ0clRITnBlU0VkZ0ExMW5qUjA1dWtuZWF4bVNKcSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 03:22:16 -0000 > -----Original Message----- > From: Ga=EBtan 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 >=20 > On Wed, Oct 24, 2018 at 04:43:45PM +0200, Thomas Monjalon wrote: > > 24/10/2018 00:39, Ga=EBtan 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_deva= rgs_insert during the vdev bus scan. Thanks Qi > > > > > > > I think the problem is in: > > > > > > > > rte_devargs_insert(struct rte_devargs *da) { > > > > int ret; > > > > > > > > ret =3D 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=3D55744d83d525 > > > > > > > > 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 interna= l > > > 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(), becaus= e > > > it cannot possibly have been inserted in the meantime (so would no= t > > > 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. > > >=20 > This would only happen if one did: >=20 > rte_devargs_insert(dev->devargs); >=20 > > > The actual issue is that the matching rte_devargs within the list > > > would be referenced by a device after a successful scan, meaning t= hat > > > 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. > > >=20 > 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. >=20 > > > > Nice rant :) >=20 > :) >=20 > -- > Ga=EBtan Rivet > 6WIND