From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id B2BE51B983; Fri, 11 May 2018 00:10:22 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 20CE8224BC; Thu, 10 May 2018 18:10:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 10 May 2018 18:10:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=DwIMHsqdQwL8GCmmu7E/JYfjAQ PJZr8k7ZMxU27UeJE=; b=XsXlWD0G9CGUFKKUpCBhAXVQVCaT9Xt6SQ+TSpujN7 BzveBYPqJD8KOWJUzKsXNLtUW7VQDNiBgtajIkyreCRSumewN7vwBBcGpwZIgHzx +lKxRJ8Nv1qclIfs+QFVVlgYiOhd+Okoodla0eiXvk4WYvXRd6yzzwAcD8swnu4c k= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DwIMHs qdQwL8GCmmu7E/JYfjAQPJZr8k7ZMxU27UeJE=; b=D/qYM8TgTRuLmY63Yey+A+ oBfdjs/BvtoI031Q3SgpeDEcKJo4Zn1MBmoWj05ToL1kqaFhETLmgx4b8Cgtdf4Z cICEtqZOQ7oFGxqjceyBhReiCseTilrOEfl1znyg3PxY11l2bZj/2r17KORL08Lv pqF2ZCFY4EDz2pOu1TMgWytazyrDcDAhuUTYNSGlK8X0r0rpmGX4DIoK2xDfScyJ LU5Yyl54LY0/HZw5UE/sBO12aP9Vmn4X6KeZbe/3fSHVSeozULx0UNl4/NUyoLau hno0c/DuYoC+bclNMKa0Sd/nzZVbs7iSx6xMjARawVW27b/CWqTussaBWDMTEaSQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 49396E43E8; Thu, 10 May 2018 18:10:21 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org, Matan Azrad , stable@dpdk.org Date: Fri, 11 May 2018 00:10:19 +0200 Message-ID: <3197799.d7CsaPIZEu@xps> In-Reply-To: <20180510133356.0c4bacb0@xeon-e3> References: <20180509094337.26112-1-thomas@monjalon.net> <20180509094337.26112-8-thomas@monjalon.net> <20180510133356.0c4bacb0@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 07/11] ethdev: add lock to port allocation check 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, 10 May 2018 22:10:22 -0000 10/05/2018 22:33, Stephen Hemminger: > On Wed, 9 May 2018 11:43:33 +0200 > Thomas Monjalon wrote: > > > > > +struct rte_eth_dev * > > +rte_eth_dev_allocated(const char *name) > > +{ > > + struct rte_eth_dev *ethdev; > > + > > + rte_eth_dev_shared_data_prepare(); > > + > > + rte_spinlock_lock(&rte_eth_dev_shared_data->ownership_lock); > > + > > + ethdev = rte_eth_dev_allocated_lock_free(name); > > + > > + rte_spinlock_unlock(&rte_eth_dev_shared_data->ownership_lock); > > + > > + return ethdev; > > +} > > + > > Not sure about this. The code it self is correct, but it creates > a racy semantic. > > If caller doesn't already hold a lock then there is no guarantee that > the device returned won't be destroyed by some other thread It is an old high level design decision in DPDK: We do not hold a lock during the whole life of a port. So it is the application responsibility to not mess its own ports. The consequence is that one port must be managed by only one thread. We can discuss the original thread design but it is out of the scope of this patchset. > or that the name was just allocated by some other process. It does not say which process allocated the port, yes. But the name is unique among processes. So the process knows for sure what to do with the port having this name.