From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH 07/11] ethdev: add lock to port allocation
 check
Date: Thu, 10 May 2018 13:33:56 -0700
Message-ID: <20180510133356.0c4bacb0@xeon-e3>
References: <20180509094337.26112-1-thomas@monjalon.net>
 <20180509094337.26112-8-thomas@monjalon.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, Matan Azrad <matan@mellanox.com>, stable@dpdk.org
To: Thomas Monjalon <thomas@monjalon.net>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pl0-f66.google.com (mail-pl0-f66.google.com
 [209.85.160.66]) by dpdk.org (Postfix) with ESMTP id 3B8441B816
 for <dev@dpdk.org>; Thu, 10 May 2018 22:33:59 +0200 (CEST)
Received: by mail-pl0-f66.google.com with SMTP id c11-v6so1948775plr.5
 for <dev@dpdk.org>; Thu, 10 May 2018 13:33:59 -0700 (PDT)
In-Reply-To: <20180509094337.26112-8-thomas@monjalon.net>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed,  9 May 2018 11:43:33 +0200
Thomas Monjalon <thomas@monjalon.net> 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 or that
the name was just allocated by some other process.