From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 827FCA00E6
for <public@inbox.dpdk.org>; Tue, 9 Jul 2019 16:00:34 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 604A51B995;
Tue, 9 Jul 2019 16:00:34 +0200 (CEST)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by dpdk.org (Postfix) with ESMTP id 034D01B95A;
Tue, 9 Jul 2019 16:00:30 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58])
by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
09 Jul 2019 07:00:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.63,470,1557212400"; d="scan'208";a="156185773"
Received: from silpixa00399498.ir.intel.com (HELO
silpixa00399498.ger.corp.intel.com) ([10.237.223.125])
by orsmga007.jf.intel.com with ESMTP; 09 Jul 2019 07:00:28 -0700
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: patrick.fu@intel.com,
stable@dpdk.org
Date: Tue, 9 Jul 2019 15:00:27 +0100
Message-Id: <a7678616c14055fb2ed3d51aa48f25f1201ce930.1562680812.git.anatoly.burakov@intel.com>
X-Mailer: git-send-email 2.17.1
Subject: [dpdk-stable] [PATCH] fbarray: fix fbarray destruction
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
Currently, when fbarray is destroyed, the fbarray structure is not
zeroed out, which leads to stale data being there and confusing
secondary process init in legacy mem mode. Fix it by always
memsetting the fbarray to zero when destroying it.
Fixes: 5b61c62cfd76 ("fbarray: add internal tailq for mapped areas")
Cc: stable@dpdk.org
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
lib/librte_eal/common/eal_common_fbarray.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_fbarray.c b/lib/librte_eal/common/eal_common_fbarray.c
index b7ddb66e9..1312f936b 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -1055,6 +1055,9 @@ rte_fbarray_destroy(struct rte_fbarray *arr)
TAILQ_REMOVE(&mem_area_tailq, tmp, next);
free(tmp);
ret = 0;
+
+ /* reset the fbarray structure */
+ memset(arr, 0, sizeof(*arr));
out:
rte_spinlock_unlock(&mem_area_lock);
return ret;
--
2.17.1