From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <remy.horton@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id E020F1E2B
 for <dev@dpdk.org>; Wed, 25 Jan 2017 13:13:37 +0100 (CET)
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
 by fmsmga101.fm.intel.com with ESMTP; 25 Jan 2017 04:13:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,283,1477983600"; d="scan'208";a="57351528"
Received: from rhorton-mobl.ger.corp.intel.com (HELO [163.33.230.15])
 ([163.33.230.15])
 by fmsmga005.fm.intel.com with ESMTP; 25 Jan 2017 04:13:15 -0800
To: Thomas Monjalon <thomas.monjalon@6wind.com>
References: <1485270071-5407-1-git-send-email-remy.horton@intel.com>
 <1844096.VBZFUxdXJL@xps13>
Cc: dev@dpdk.org
From: Remy Horton <remy.horton@intel.com>
Organization: Intel Shannon Limited
Message-ID: <62d6a8d5-5a21-cdd8-6a7a-d81bef102313@intel.com>
Date: Wed, 25 Jan 2017 12:13:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <1844096.VBZFUxdXJL@xps13>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix multi-process NULL
	dereference crashes
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2017 12:13:38 -0000


On 25/01/2017 11:56, Thomas Monjalon wrote:
[..]
> It does not describe exactly the use-case it is fixing (same in commit message).
> I guess you saw an issue when creating a vdev in the primary process and
> another one in a secondary process, erasing the data of the first one.

In my use-case the secondary process is proc_info, which appeared to be 
blanking the shared memory then leaving the NULL-pointer landmines for 
the primary process to land on. I'm not entirely sure why this type of 
secondary process needs to be running any ethdev startup code at all, as 
all it is doing is pulling data out of shared memory..


> My previous proposal was:
> 	memset(eth_dev->data, 0, sizeof(*eth_dev->data))
> It is better to avoid reference to the global array rte_eth_dev_data.

Git rebase screwed up, and it got lost en-route :(

..Remy