From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2D258A00BE; Fri, 12 Jun 2020 05:46:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8AFC61BE99; Fri, 12 Jun 2020 05:46:18 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 531231B91B for ; Fri, 12 Jun 2020 05:46:14 +0200 (CEST) IronPort-SDR: RuUBOqcOS1zEme1VuVKb6OFa4KB79lY7jhNs6wyObWDBqAM5Ayo6lkbOVcMeKixNDfPcrRNiYv fCRRGyZox9/g== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2020 20:46:14 -0700 IronPort-SDR: /70ARYdmjMuPJnXqiMWGjXhIh9AbgUk22V19kFwF1WWgBmHXLQKfXXSnpi4zLVPNma6L4DWeZm 8HPWcF50GX7A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,501,1583222400"; d="scan'208";a="289759494" Received: from intel.sh.intel.com ([10.239.255.18]) by orsmga002.jf.intel.com with ESMTP; 11 Jun 2020 20:46:12 -0700 From: Guinan Sun To: dev@dpdk.org Cc: Guinan Sun , Robert Konklewski Date: Fri, 12 Jun 2020 03:23:55 +0000 Message-Id: <20200612032410.20864-7-guinanx.sun@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200612032410.20864-1-guinanx.sun@intel.com> References: <20200612032410.20864-1-guinanx.sun@intel.com> Subject: [dpdk-dev] [PATCH 06/21] net/ixgbe/base: resolve infinite recursion on PCIe link down 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" In some corner cases the functions ixgbe_clear_rar_generic and ixgbe_clear_vmdq_generic may call one another leading to infinite recursion. When ixgbe_clear_vmdq_generic is called with IXGBE_CLEAR_VMDQ_ALL flag, it's going to clear MPSAR registers, and proceed to call ixgbe_clear_rar_generic, which in turn will clear the RAR registers, and recursively call back ixgbe_clear_vmdq_generic. Normally, the latter would detect that MPSAR registers have already been cleared and terminate the recursion. However, when PCIe link is down, and before the driver has had the opportunity to shut itself down, all register reads return 0xFFFFFFFF, and all register writes fail silently. In such case, because ixgbe_clear_vmdq_generic blindly assumes that clearing MPSAR registers succeeded, it's going to always call ixgbe_clear_rar_generic, which in turn will always call back ixgbe_clear_vmdq_generic, creating inifinite recursion. This patch re-reads MPSAR register values after they had been cleared. In case of PCIe link failure, the values read will be non-zero, which will terminate the recursion. On the other hand, under normal circumstances the value read from MPSAR registers is going to be equal to the value previously written, so this patch is expected not to cause any regressions. Testing Hints (required if no HSD): Bring down the adapter's parent PCIe bridge. Signed-off-by: Robert Konklewski Signed-off-by: Guinan Sun --- drivers/net/ixgbe/base/ixgbe_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ixgbe/base/ixgbe_common.c b/drivers/net/ixgbe/base/ixgbe_common.c index 89ae2b462..420ad977b 100644 --- a/drivers/net/ixgbe/base/ixgbe_common.c +++ b/drivers/net/ixgbe/base/ixgbe_common.c @@ -3778,11 +3778,11 @@ s32 ixgbe_clear_vmdq_generic(struct ixgbe_hw *hw, u32 rar, u32 vmdq) if (vmdq == IXGBE_CLEAR_VMDQ_ALL) { if (mpsar_lo) { IXGBE_WRITE_REG(hw, IXGBE_MPSAR_LO(rar), 0); - mpsar_lo = 0; + mpsar_lo = IXGBE_READ_REG(hw, IXGBE_MPSAR_LO(rar)); } if (mpsar_hi) { IXGBE_WRITE_REG(hw, IXGBE_MPSAR_HI(rar), 0); - mpsar_hi = 0; + mpsar_hi = IXGBE_READ_REG(hw, IXGBE_MPSAR_HI(rar)); } } else if (vmdq < 32) { mpsar_lo &= ~(1 << vmdq); -- 2.17.1