From mboxrd@z Thu Jan 1 00:00:00 1970 From: Remy Horton Subject: Re: [PATCH v2] ethdev: fix multi-process NULL dereference crashes Date: Wed, 25 Jan 2017 12:13:14 +0000 Message-ID: <62d6a8d5-5a21-cdd8-6a7a-d81bef102313@intel.com> References: <1485270071-5407-1-git-send-email-remy.horton@intel.com> <1844096.VBZFUxdXJL@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Thomas Monjalon Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id E020F1E2B for ; Wed, 25 Jan 2017 13:13:37 +0100 (CET) In-Reply-To: <1844096.VBZFUxdXJL@xps13> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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