From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 5DDFF201 for ; Mon, 12 Nov 2018 01:47:53 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 22524348; Sun, 11 Nov 2018 19:47:52 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 11 Nov 2018 19:47:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=M1cja0vHpWEfYMslLtLZrXAcY5MZ5SuLK5pbwsER3Vw=; b=cjzo/8X6FCWq sGsMi/Q2u+aPXdaHZyhX+SYmALx12JEU+jWKKXjUS4HdaLNlOxVuaBsP+Bmg1eDy Noja8hk8m747l8AoCRDXfQX42widd/cYqPCGgLKOvXh4jksG90t0ZjyIFT7Ytj2+ aMkNCMWFcQFhdKcBmewWC0EHICrTIak= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=M1cja0vHpWEfYMslLtLZrXAcY5MZ5SuLK5pbwsER3 Vw=; b=mCKetxqR/S991+8GdHMrTHUOz8N8FbMye2YjfbTNA+gxF/J1gRgj/zOv0 +3tfvSjxBFaNWPli2URXRPnUuTnNHb2aiorc0/54JZlY0auC9EC3mCopkrITtWfw pLcFaAyvDli1hexAezDNTcFlxWZTqSPtakNLelxf9QHPxv6KXcwqhzbuBz7rFRDY WXJXH4UHTXWLOT5Jb5k1PisvVtuZe3YovaY7k9eWilB8dNgeUuIxrcngCS60ChbZ c1LniGBN0Hz72JufeFmb2Onh+dHdmTkKLzIejamsuq4+nG6BeXW/YqZMQ8Iel47t EgDjSYzNjYPZW6PiJGS9J14mbKfyA== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 90B8D102A0; Sun, 11 Nov 2018 19:47:50 -0500 (EST) From: Thomas Monjalon To: "Zhang, Qi Z" , "Stojaczyk, Dariusz" Cc: dev@dpdk.org, =?ISO-8859-1?Q?Ga=EBtan?= Rivet , Dariusz Stojaczyk Date: Mon, 12 Nov 2018 01:47:49 +0100 Message-ID: <1656633.l3hu02U1SK@xps> In-Reply-To: <20181106234003.qhimuexm6z4mp7pr@bidouze.vm.6wind.com> References: <20181105070447.67700-1-dariusz.stojaczyk@intel.com> <039ED4275CED7440929022BC67E70611532E04E5@SHSMSX103.ccr.corp.intel.com> <20181106234003.qhimuexm6z4mp7pr@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH v2] 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, 12 Nov 2018 00:47:53 -0000 07/11/2018 00:40, Ga=EBtan Rivet: > On Tue, Nov 06, 2018 at 10:21:38PM +0000, Zhang, Qi Z wrote: > > From: Dariusz Stojaczyk [mailto:darek.stojaczyk@gmail.com] > > > From: Darek Stojaczyk > > >=20 > > > Bus rescan is done e.g. during the device hotplug, where devargs are > > > re-allocated. By not updating the rte_device->devargs pointer we pote= ntially > > > make it a dangling one, as previous devargs could have been (or will = be soon) > > > freed. > >=20 > > Yes, this is the similar issue we met on vdev. > >=20 > > The key problem is we have rte_devargs_insert will destroy a devargs wh= ich is still referenced by a rte_device > > I'm thinking , why not just keep always keep a snapshot of devargs in r= te_device to make things simple? > > We could introduce a API like rte_dev_assign_devargs(dev, devargs) whic= h handled the clone and destroy stuff and can be used for all buses. > > If that idea is acceptable, I would prefer the issue in this patch coul= d be fixed in pci_name_set by clone a new copy as workaround. > >=20 >=20 > I agree that it would be useful to have >=20 > rte_devargs_map(devargs, device); >=20 > That will link safely a devargs to a device, but cloning is overkill. >=20 > I disagree that dangling pointers and loose references is fixed by > introducing more cloning and copies of stuff here and there. >=20 > We must tighten the device -> devargs coupling, not loosen it. This issue is fixed with a different approach: http://git.dpdk.org/dpdk/commit/?id=3Dc7ad7754 devargs: do not replace already inserted device