From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 9743014EC for ; Mon, 5 Nov 2018 17:28:02 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id k15-v6so7241958wre.12 for ; Mon, 05 Nov 2018 08:28:02 -0800 (PST) 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=rVtP+0GtouTYQe9p71P4HO7PxBv0+EUWAAs29cYivbY=; b=f2QXBdSRlG6wjD4oLaMKpUjHRP19vLYEdp7+Pg5tzyaL8ItE0t0NCU2bO5/Hk2gXST tMiW4ZDJWjGoxI4twxOLOd4nEbmY8V/c/+AvLzWILPoa1OidpVS+YpsnrkjX0Q9io6l8 bXwsu9TRqueJeY16/Bw4b6f641BkVjzPEYxQaxghXd3iITild8Aax4no1ttqzrZjO1C6 kfIZck57fCJkmzxUMHy7aD6qqNCdvxZtgMVASNl27L653AuCRQyEyfOweW362XTJKbHl llL4gEuZ2IEXXnmy2y0lH2N4KbU+mi/2KqVOHfixG4B5oaJD4DEsRlBJ9LyyTolGj/xj fqIA== 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=rVtP+0GtouTYQe9p71P4HO7PxBv0+EUWAAs29cYivbY=; b=K36o/8H6Cwu9vkrq0TfmWx7rnQ82QSj6CNt0DDY3e4VSdJq/0GVSHuewO72x3ZvSGv DLN79t224Y0dCwZCdGgKg/7+FNqUA10+daehw7dZFX55h+9cc8WsGTzqK867DHxRCPN6 0AZ/+WyOEQSJWkUjnzONIWcx9Tz52zB/T9RpY9SUAaTH9/Hl0RsII2spZXdnMR13AbC/ zUf+fSkBdoz7dyCrXNyUYYsA3xZXf61JKHO5rxecb21mBARyFiq8Zmzj7PSZ90H9utXK X6eDrgFVHZB7ZwoMKyA7cGFwFQwZQhRkZJPmzTiqv5+UsqUR2RhP2ab3V02LMGuTC2L7 fZAw== X-Gm-Message-State: AGRZ1gIdpTNSFcIjmmHkeK00JpgRiPb9g+hjcu3dqbqKPd0e1XKuAw/O nPN4uOU+u8ArRGwyUvAJb71gaw== X-Google-Smtp-Source: AJdET5eSgIjAFCDOc6kH5AbYRec0jnK5ufei/FVnSJh6xllPNBJXaeVkk32Ytciy6NsIwAQgrMcCxQ== X-Received: by 2002:a5d:44d2:: with SMTP id z18-v6mr12037937wrr.236.1541435281970; Mon, 05 Nov 2018 08:28:01 -0800 (PST) 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 p188-v6sm9496853wmp.31.2018.11.05.08.28.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Nov 2018 08:28:01 -0800 (PST) Date: Mon, 5 Nov 2018 17:27:42 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: "Stojaczyk, Dariusz" Cc: "dev@dpdk.org" , "thomas@monjalon.net" , "Zhang, Qi Z" Message-ID: <20181105162742.eako45onrhmjgfab@bidouze.vm.6wind.com> References: <20181105070447.67700-1-dariusz.stojaczyk@intel.com> <20181105141033.z3i3qfjoh6z26f4v@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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 16:28:02 -0000 On Mon, Nov 05, 2018 at 02:52:00PM +0000, Stojaczyk, Dariusz wrote: > Hi Gaetan, > > > -----Original Message----- > > From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com] > > Subject: Re: [dpdk-dev] [PATCH 1/3] bus/pci: update device devargs on each > > rescan > > > > Hi Darek, > > > > 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); > > > > This is rather unfortunate to call pci_name_set() > > to trigger the mapping devargs <-> devices. > > > > pci_devargs_lookup could be made non-static instead, > > if that's sufficient. > > This is unfortunately trigerred by the generic eal device hotplug path which looks as follows: > > da = 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 new bus callback for updating devargs of only a single device and that would be a really, realy ugly overkill. Thomas already mentioned in the subsequent patch within this series that we might want to re-think the devargs design in the next release. > No, of course, I'm not saying to make pci_devargs_lookup public, only private to the PCI bus, and within the bus, non-static. This way, instead of calling pci_name_set(), you call instead only pci_devargs_lookup(). > > 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, but IMO it's enforced by the current rte_devargs design. Besides, this used to be the original behavior before 55e411b301c3 ("bus/pci: fix resource mapping override"). > > Thanks, > D. > > > > > > > > > > -- > > Gaëtan Rivet > > 6WIND -- Gaëtan Rivet 6WIND