From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 2EC072082 for ; Wed, 7 Nov 2018 00:40:24 +0100 (CET) Received: by mail-wm1-f68.google.com with SMTP id t15-v6so6211164wmt.0 for ; Tue, 06 Nov 2018 15:40:24 -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=RA4FjENBXysaaUTJaJluAVr7t+Q8MIocZgxx+bbg//g=; b=17bvP8KKXqMeYpawU6ETh205VjeATRcJBhAJwlqYz/8Iqk6hmyNPkMwdABZWMGkO8w haqJC9CxK3IqhL+8oysjPvaL3rkCTYkBIV4YbGmgw6wxJY7pZgqUNR4A6/9WUsNDiNDg c4wVwAe6XiyA4rqrzAqCRByypg5z/fcNFAEb0JuIIzsykMjrhk78tBjQCKxiLAmcW1qw RVD/rAWr/RIVho3U9yxgrrdJbvJg+swC7jAYRtMItmu/aX5m0KR2I8XqtvYMuKzLwPCN oaJffzuZFsmzqSiZ2j+NBgbslanZ6MkqAVRS5+3ysF5R85Fuv/sYL7ADI2/9xS6DNJdO I89Q== 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=RA4FjENBXysaaUTJaJluAVr7t+Q8MIocZgxx+bbg//g=; b=XL0HUHOkX/vgdJEp/3dzl4fz96d+l7OVBf+HY3E4CBt2X6DLpUOIbLVfJKoogSIJfv dnp9iZpeMiHeRIIAgPF7RI5nxS2rUMXsnqNPxC7pKZII0ubgjZ7Tf4w1vRW+UhWBzwl8 FyGsyjKP1Dl+V82RWaOewIZ0+yux4DIMGeswDQSOBL+O2aMH5TRNymyZskPcqSgmIwNW ERI6BQF1ejJpg5JyaNxyxHItYI4/7owJI0pSApKO3JKT41A9NqtERq3DmTg7y3wGs+F4 GccO8hCXgWk4qyYhADx9LULg9Mo1sKGXVdYM15Lz0H5BOG7PiLo002CAiEOCyihcIZz5 4tzA== X-Gm-Message-State: AGRZ1gIreGqb3pjUlPQBZGk8lFZGxYKRBHMpEeBr9SG4kE3y1FzoYFWX B02lm9LgE0wuRtsuJaUXUlSnjw== X-Google-Smtp-Source: AJdET5eCsIWNZ6DPKuMehRld+xSYGnS+gmRXGzFcLiCx15rL/OmxynPKgnypHm004frcMDQXYOsKog== X-Received: by 2002:a1c:af07:: with SMTP id y7-v6mr23672wme.12.1541547623491; Tue, 06 Nov 2018 15:40:23 -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 e10-v6sm3391640wmg.23.2018.11.06.15.40.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 06 Nov 2018 15:40:22 -0800 (PST) Date: Wed, 7 Nov 2018 00:40:03 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: "Zhang, Qi Z" Cc: Dariusz Stojaczyk , "dev@dpdk.org" , "Stojaczyk, Dariusz" Message-ID: <20181106234003.qhimuexm6z4mp7pr@bidouze.vm.6wind.com> References: <20181105070447.67700-1-dariusz.stojaczyk@intel.com> <20181106054015.28280-1-darek.stojaczyk@gmail.com> <039ED4275CED7440929022BC67E70611532E04E5@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: <039ED4275CED7440929022BC67E70611532E04E5@SHSMSX103.ccr.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) 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: Tue, 06 Nov 2018 23:40:24 -0000 On Tue, Nov 06, 2018 at 10:21:38PM +0000, Zhang, Qi Z wrote: > > > > -----Original Message----- > > From: Dariusz Stojaczyk [mailto:darek.stojaczyk@gmail.com] > > Sent: Monday, November 5, 2018 10:40 PM > > To: dev@dpdk.org; gaetan.rivet@6wind.com > > Cc: Stojaczyk, Dariusz ; Zhang, Qi Z > > > > Subject: [PATCH v2] bus/pci: update device devargs on each rescan > > > > From: Darek Stojaczyk > > > > 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. > > Yes, this is the similar issue we met on vdev. > > The key problem is we have rte_devargs_insert will destroy a devargs which is still referenced by a rte_device > I'm thinking , why not just keep always keep a snapshot of devargs in rte_device to make things simple? > We could introduce a API like rte_dev_assign_devargs(dev, devargs) which 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 could be fixed in pci_name_set by clone a new copy as workaround. > I agree that it would be useful to have rte_devargs_map(devargs, device); That will link safely a devargs to a device, but cloning is overkill. I disagree that dangling pointers and loose references is fixed by introducing more cloning and copies of stuff here and there. We must tighten the device -> devargs coupling, not loosen it. -- Gaëtan Rivet 6WIND