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 439594C9C for ; Mon, 5 Nov 2018 15:52:04 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 06:52:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,468,1534834800"; d="scan'208";a="278455928" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga006.fm.intel.com with ESMTP; 05 Nov 2018 06:52:03 -0800 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 06:52:02 -0800 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 06:52:03 -0800 Received: from hasmsx105.ger.corp.intel.com ([169.254.1.193]) by HASMSX110.ger.corp.intel.com ([169.254.6.157]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 16:52:00 +0200 From: "Stojaczyk, Dariusz" To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: "dev@dpdk.org" , "thomas@monjalon.net" , "Zhang, Qi Z" Thread-Topic: [dpdk-dev] [PATCH 1/3] bus/pci: update device devargs on each rescan Thread-Index: AQHUdNZh7AdVdUSjpkiBzxpFoU0Vi6VBF22AgAAiWEA= Date: Mon, 5 Nov 2018 14:52:00 +0000 Message-ID: References: <20181105070447.67700-1-dariusz.stojaczyk@intel.com> <20181105141033.z3i3qfjoh6z26f4v@bidouze.vm.6wind.com> In-Reply-To: <20181105141033.z3i3qfjoh6z26f4v@bidouze.vm.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODJjMjUzYTEtODdkMS00YzdmLWE3YmItYmJlOGViYzMyZTA1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieVJWQ0loQjNjT3FQM055NndVVkZhYTl4dzZSVFdFaHJJWnpzbFQwVmMwSXJSR093dzRvOElzczRtXC9EWk5NTkUifQ== x-ctpclassification: CTP_NT x-originating-ip: [10.102.11.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/3] bus/pci: update device devargs on each rescan 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: Mon, 05 Nov 2018 14:52:05 -0000 Hi Gaetan, > -----Original Message----- > From: Ga=EBtan Rivet [mailto:gaetan.rivet@6wind.com] > Subject: Re: [dpdk-dev] [PATCH 1/3] bus/pci: update device devargs on eac= h > rescan >=20 > Hi Darek, >=20 > On Mon, Nov 05, 2018 at 08:04:45AM +0100, Darek Stojaczyk wrote: > > 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. > > > > Fixes: 55e411b301c3 ("bus/pci: fix resource mapping override") > > Cc: qi.z.zhang@intel.com > > > > Signed-off-by: Darek Stojaczyk > > --- > > drivers/bus/pci/linux/pci.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c > > index f87533c5c..f3172960e 100644 > > --- a/drivers/bus/pci/linux/pci.c > > +++ b/drivers/bus/pci/linux/pci.c > > @@ -349,10 +349,10 @@ pci_scan_one(const char *dirname, const struct > rte_pci_addr *addr) > > if (ret < 0) { > > rte_pci_insert_device(dev2, dev); > > } else { /* already registered */ > > + pci_name_set(dev2); >=20 > This is rather unfortunate to call pci_name_set() > to trigger the mapping devargs <-> devices. >=20 > pci_devargs_lookup could be made non-static instead, > if that's sufficient.=20 This is unfortunately trigerred by the generic eal device hotplug path whic= h looks as follows: da =3D calloc(sizeof rte_devargs); [...] rte_devargs_insert(da); # frees the previous devargs that rte_device still = references da->bus->scan(); # this should update the dangling devargs/name pointer in = rte_device Instead of making pci_devargs_lookup public, we would have to introduce a n= ew bus callback for updating devargs of only a single device and that would= be a really, realy ugly overkill. Thomas already mentioned in the subseque= nt patch within this series that we might want to re-think the devargs desi= gn in the next release. > Given that the PCI id matches because the device > is a duplicate (already registered), then the name itself probably does > not need to be updated. The issue here was that old devargs/name could have been freed. The new name is the same as the old one, it's just in a different buffer. I know calling pci_name_set() on each device during scan is not perfect, bu= t IMO it's enforced by the current rte_devargs design. Besides, this used t= o be the original behavior before 55e411b301c3 ("bus/pci: fix resource mapp= ing override"). Thanks, D. >=20 > > >=20 > -- > Ga=EBtan Rivet > 6WIND