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 79F63A0523; Thu, 2 Jul 2020 05:31:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9871B1D60D; Thu, 2 Jul 2020 05:30:50 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id B30C31D60B for ; Thu, 2 Jul 2020 05:30:48 +0200 (CEST) IronPort-SDR: u6IVW6vgM6FPNdXkf+YF+bjdqS9Qg9uzdI2YKpLfwj/rtG4xgQ81D9bHF5HHhsbIacGLkSJVXZ nCcZYp2pBwfg== X-IronPort-AV: E=McAfee;i="6000,8403,9669"; a="144300617" X-IronPort-AV: E=Sophos;i="5.75,302,1589266800"; d="scan'208";a="144300617" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 20:30:48 -0700 IronPort-SDR: Oi0haSAxvht/om4tq1qtZnrs6qYkOd1BhVs6oSHmzEjlN9s6pcCRceI9yaO656BOfCqFll8Ojv drlxdMrt5m2g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,302,1589266800"; d="scan'208";a="295751524" Received: from intel.sh.intel.com ([10.239.255.18]) by orsmga002.jf.intel.com with ESMTP; 01 Jul 2020 20:30:46 -0700 From: Guinan Sun To: dev@dpdk.org Cc: Jeff Guo , Zhao1 Wei , Guinan Sun , Robert Konklewski Date: Thu, 2 Jul 2020 03:13:15 +0000 Message-Id: <20200702031329.4495-7-guinanx.sun@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200702031329.4495-1-guinanx.sun@intel.com> References: <20200612032410.20864-1-guinanx.sun@intel.com> <20200702031329.4495-1-guinanx.sun@intel.com> Subject: [dpdk-dev] [PATCH v2 06/20] 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. 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