From patchwork Fri Jan 24 21:32:03 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949937 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D54951DA103 for ; Fri, 24 Jan 2025 21:32:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754342; cv=none; b=ZV1SMHHBhL9W65EAbDA0QL5nOWYmn+E6Qdozs9dI+Ez6vZ7sWv735rb5V+mwPE9PTFWiXa5dncdxVYQdlg3oTn+91gLRg0/uyBV9z2ms/pFsZmnk4STS+4rwHdZXs4UDHzzL+sKZUd07Syt3XSv1I/O38AATBjJG7LeraxqropQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754342; c=relaxed/simple; bh=feeTAPxAtgZE5fkK3OWNHler8ZlsQBmjQ9owo5BQKaY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Dp/KaXdn9JSmj8J7E06RaaPt+4mtrqfWPS/57odeVVybh7FcgJTNKyvqitiF75AtbSi6vsgIGxwiMhx0ce4X3L6W4WMIMqVrlKFWsFJElsE66hookYBFHvQHd5ZwtwLYmGhEjy2XrawGXsD41or71HvXxA6dqcjg9IuXPZInnDk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=n7klhw2P; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="n7klhw2P" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754339; x=1769290339; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=feeTAPxAtgZE5fkK3OWNHler8ZlsQBmjQ9owo5BQKaY=; b=n7klhw2P1falzorrCT0JrStsenq5djuGh5C/HLtnRqeTYjb9gn7ylxmm ydnDWTldJZ1l9jDv6UsdU5JEV4x6lF6MKsnHm4Hte/dfcTFSC0UASveS8 QlWeeV/f/ybgdFi7Db/d2z4bV6u2uAHqNIMmNH1A+G85K2UNSWNz16CPm q10gXNbp4i6TqA/lBBtk3t583wmq3btYrGovUNz9whRlZTQFoM3NbH2XX wugfSanau05tDN3R80J5VAQtgkjUovvmfi6PUMtwa1w67jHCSBsMTPjsk MA7GMIIJl6QLfGdSPRN9YZEgNOpQnnmBBETczzflQbiVctTuMv9CRd0t1 g==; X-CSE-ConnectionGUID: Dokj3Ef9StKbbeG8pGAKMw== X-CSE-MsgGUID: dVI8hamfTZWh9OCNM7SizQ== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140381" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140381" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:17 -0800 X-CSE-ConnectionGUID: WjY6VrgrTMixWCXCRztdnQ== X-CSE-MsgGUID: yPLacua6Tgi1X6nCgq6DCA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861076" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:16 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Emil Tantilov , anthony.l.nguyen@intel.com, aleksander.lobakin@intel.com, przemyslaw.kitszel@intel.com, joshua.a.hay@intel.com, decot@google.com, willemb@google.com, rlance@google.com, Sridhar Samudrala , Krishneil Singh Subject: [PATCH net 1/8] idpf: add read memory barrier when checking descriptor done bit Date: Fri, 24 Jan 2025 13:32:03 -0800 Message-ID: <20250124213213.1328775-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Emil Tantilov Add read memory barrier to ensure the order of operations when accessing control queue descriptors. Specifically, we want to avoid cases where loads can be reordered: 1. Load #1 is dispatched to read descriptor flags. 2. Load #2 is dispatched to read some other field from the descriptor. 3. Load #2 completes, accessing memory/cache at a point in time when the DD flag is zero. 4. NIC DMA overwrites the descriptor, now the DD flag is one. 5. Any fields loaded before step 4 are now inconsistent with the actual descriptor state. Add read memory barrier between steps 1 and 2, so that load #2 is not executed until load #1 has completed. Fixes: 8077c727561a ("idpf: add controlq init and reset checks") Reviewed-by: Przemek Kitszel Reviewed-by: Sridhar Samudrala Suggested-by: Lance Richardson Signed-off-by: Emil Tantilov Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_controlq.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/idpf/idpf_controlq.c b/drivers/net/ethernet/intel/idpf/idpf_controlq.c index 4849590a5591..b28991dd1870 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_controlq.c +++ b/drivers/net/ethernet/intel/idpf/idpf_controlq.c @@ -376,6 +376,9 @@ int idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 *clean_count, if (!(le16_to_cpu(desc->flags) & IDPF_CTLQ_FLAG_DD)) break; + /* Ensure no other fields are read until DD flag is checked */ + dma_rmb(); + /* strip off FW internal code */ desc_err = le16_to_cpu(desc->ret_val) & 0xff; @@ -563,6 +566,9 @@ int idpf_ctlq_recv(struct idpf_ctlq_info *cq, u16 *num_q_msg, if (!(flags & IDPF_CTLQ_FLAG_DD)) break; + /* Ensure no other fields are read until DD flag is checked */ + dma_rmb(); + q_msg[i].vmvf_type = (flags & (IDPF_CTLQ_FLAG_FTYPE_VM | IDPF_CTLQ_FLAG_FTYPE_PF)) >> From patchwork Fri Jan 24 21:32:04 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949936 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1D681DD520 for ; Fri, 24 Jan 2025 21:32:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754342; cv=none; b=VRgayDWduy9mZJWMAFEMKmF9aM6mkgpA2tfC7V2mR5J1wgOkG6MB/Nx2G2RMVucQ8LXmR4qTGrRI76juSk6dz4g9pI9ik1U4Wxe1nwEeqTsbkqpa+DEPCYKOQzwv10RlU1e4QMUuuwMe2Z63JICDR8ghWuy5pwBkid//AxsFubA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754342; c=relaxed/simple; bh=7u2607bVEyMZVmBYLyxGWvjBem+61Nd2tTBfIpsM5X4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ys+ugQ2KrH/ggWVO5xGXBMDcckl5by//008xxOrvJZcxVCmM7zVEMBLXzb3jgeo8OiHbLYRjSQjJZiptkPn4rOB2bwppGi1aVErtOawoqPSZB5CqSo7DSiGQCrWdzYV6OyWTbsvWEwid5aZu1GCWO5oun8uPtQrA4I7Ehmo5BNY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MEg27CYf; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MEg27CYf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754340; x=1769290340; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=7u2607bVEyMZVmBYLyxGWvjBem+61Nd2tTBfIpsM5X4=; b=MEg27CYfcL5Ud7B2NfXkCJ/LCqA57pHz4d325nlATaoDFTdp/nA//1Rz 4LFJTvSMPx9AJklwpq73A95VgWsbIfkTtlGBYYpATdexdBly+lQQ4iXSr 23UmPT3vh3EcvgRaY6uqAlwV0CKDMB7SLoo7c6XOh2gyppqnztv+EM4GD TBmHwRyCXFSF7VXKCDq68gK+rEWZ85Y/jgSngCDuKV/q44qrUgXiUtTmU LPWpG3NFheHyxRQ76RTwPHlEhbVRv+qDKLjJ5YFOhKAqFcKHPiYdj96Jt Ocm5Tz0uj1ru8RKaI0cSI1/wzWVOBfEJshSKKdcU5D1N610MJzKH3ltA/ g==; X-CSE-ConnectionGUID: hlzIxwFOS3K1zxFcLFCYMg== X-CSE-MsgGUID: QcLTsp07Q66Dl5+nAizJfw== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140390" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140390" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:17 -0800 X-CSE-ConnectionGUID: I5uXn3ENRN2A1qSJ3BRZ+w== X-CSE-MsgGUID: Vi/F3raoQOWEHusBJdYVaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861079" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:17 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Emil Tantilov , anthony.l.nguyen@intel.com, larysa.zaremba@intel.com, aleksander.lobakin@intel.com, decot@google.com, willemb@google.com, Simon Horman , Krishneil Singh Subject: [PATCH net 2/8] idpf: fix transaction timeouts on reset Date: Fri, 24 Jan 2025 13:32:04 -0800 Message-ID: <20250124213213.1328775-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Emil Tantilov Restore the call to idpf_vc_xn_shutdown() at the beginning of idpf_vc_core_deinit() provided the function is not called on remove. In the reset path the mailbox is destroyed, leading to all transactions timing out. Fixes: 09d0fb5cb30e ("idpf: deinit virtchnl transaction manager after vport and vectors") Reviewed-by: Larysa Zaremba Signed-off-by: Emil Tantilov Reviewed-by: Simon Horman Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index d46c95f91b0d..7639d520b806 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c @@ -3077,12 +3077,21 @@ int idpf_vc_core_init(struct idpf_adapter *adapter) */ void idpf_vc_core_deinit(struct idpf_adapter *adapter) { + bool remove_in_prog; + if (!test_bit(IDPF_VC_CORE_INIT, adapter->flags)) return; + /* Avoid transaction timeouts when called during reset */ + remove_in_prog = test_bit(IDPF_REMOVE_IN_PROG, adapter->flags); + if (!remove_in_prog) + idpf_vc_xn_shutdown(adapter->vcxn_mngr); + idpf_deinit_task(adapter); idpf_intr_rel(adapter); - idpf_vc_xn_shutdown(adapter->vcxn_mngr); + + if (remove_in_prog) + idpf_vc_xn_shutdown(adapter->vcxn_mngr); cancel_delayed_work_sync(&adapter->serv_task); cancel_delayed_work_sync(&adapter->mbx_task); From patchwork Fri Jan 24 21:32:05 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949938 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 204E51DDC2F for ; Fri, 24 Jan 2025 21:32:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754342; cv=none; b=Y+it/EyvIhTjLUhPFLkyPMXOMxTh17A2cs0MKgfTtiLYGctRdMaByyjdN455jtDNMMohvGCusSU+NUVw3Fxu7E+14wWGLb94zYp24qXAIvjnlWZgjR/KosDZqsth/uROEMcOKwS5R+qNiExS1YuFj4lTtlhww2GYb3Cr085RuDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754342; c=relaxed/simple; bh=0beSTsiL0hSjQwcJ07iG4UnIPxjt0aY9WhObxi/LZYE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LUimAbDfRnA/3KkqmQ5kAVbQv4AKcS5D1YrZGlbiqsW6MitYPkn4qzKa7QEaldzo/AQZdX2ol3lNXPPFyyfZQg3ooOLovepYFPaoZFwOniV1r+D9teBekgHY1LyPEFqx8HyKZAX+TImInW8n09g9Y++RjtuN0pNOb2p0NMB73HQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=TVBM9GV+; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="TVBM9GV+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754341; x=1769290341; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0beSTsiL0hSjQwcJ07iG4UnIPxjt0aY9WhObxi/LZYE=; b=TVBM9GV+IRXieNryvqNq/tW/auQ75l/bRYhfzZcwzRGCy9+zkILE5G/m p+kQrVDAnxWFz8B0FGvbSvgIcMhfRhapEimhOEOFW9qmbigNt8tqvRvs2 ZZ2huPYB9/OrL0DtWhrhDwyI2UYeXAZy46rojsFpOwDft8w46LBYHTBpX dHBHEQvFUGOaB68B1GlQxBpaGgHkMtllsETEpV2Z2WgA8l2LYuSYRc3VM heGS2kW1cluH1WqzXVZbmP4eZWJjpUpUwaJZcde0H1YYXnU2nPzwxuZjp ri7tD0opIC6li3BJKNzKF2K4ESBUKjfBJhLYzsSyoNIIcRHIZiDQN/EkQ Q==; X-CSE-ConnectionGUID: fzAaVxB3Qtea5u1FZvCd4g== X-CSE-MsgGUID: mz92tVZTSqeFOvOetsQsJg== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140395" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140395" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:17 -0800 X-CSE-ConnectionGUID: K+lvaiEBQ62jJrI6M5VAyw== X-CSE-MsgGUID: EQ/xM1E5TgmtsnAJBYzFdQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861083" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:17 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Manoj Vishwanathan , anthony.l.nguyen@intel.com, emil.s.tantilov@intel.com, anjali.singhai@intel.com, przemyslaw.kitszel@intel.com, sridhar.samudrala@intel.com, jacob.e.keller@intel.com, pavan.kumar.linga@intel.com, vivekmr@google.com, brianvv.kernel@gmail.com, decot@google.com, Brian Vazquez , Krishneil Singh Subject: [PATCH net 3/8] idpf: Acquire the lock before accessing the xn->salt Date: Fri, 24 Jan 2025 13:32:05 -0800 Message-ID: <20250124213213.1328775-4-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Manoj Vishwanathan The transaction salt was being accessed before acquiring the idpf_vc_xn_lock when idpf has to forward the virtchnl reply. Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Signed-off-by: Manoj Vishwanathan Signed-off-by: David Decotigny Signed-off-by: Brian Vazquez Reviewed-by: Jacob Keller Reviewed-by: Pavan Kumar Linga Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index 7639d520b806..99bdb95bf226 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c @@ -612,14 +612,15 @@ idpf_vc_xn_forward_reply(struct idpf_adapter *adapter, return -EINVAL; } xn = &adapter->vcxn_mngr->ring[xn_idx]; + idpf_vc_xn_lock(xn); salt = FIELD_GET(IDPF_VC_XN_SALT_M, msg_info); if (xn->salt != salt) { dev_err_ratelimited(&adapter->pdev->dev, "Transaction salt does not match (%02x != %02x)\n", xn->salt, salt); + idpf_vc_xn_unlock(xn); return -EINVAL; } - idpf_vc_xn_lock(xn); switch (xn->state) { case IDPF_VC_XN_WAITING: /* success */ From patchwork Fri Jan 24 21:32:06 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949939 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 405B61E7C27 for ; Fri, 24 Jan 2025 21:32:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754343; cv=none; b=hHy6mw8kwjtIYOAYEVZS1iElXAsscRdCOBXTs/q/rZ1k8uHEEGTJPDIwXOQJx65bRlgKdOoAReEAGuOsA51EdTxgYq3r3m6ODuzCOKGSGY1xs1Oq7IIf7U/WfvcddGkBZ1sEGO8RtbSubk1jxQikVOTiBax4aFzRif7AFFpL24Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754343; c=relaxed/simple; bh=Iv3SD0WsKeyqpIbRwKokjasKKgiPm8GebeHbkz3lK3w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YFCLxfZ9W/vJ12aPIoOzxmNUDeTdE1UKbuRjVbqNIfO4FnW6o5RFtbzflZ3+S1uIbzTYUuNcy9bEiq7rHM5+nOb8ef01ltD/DyGXnxutv7aIo4frtTE5FvsN5LUnB46DgpjRYitXKmIc6YSJJ8foNmZSY2HfjK4seC+0azv9puY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=bUfjYBqB; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="bUfjYBqB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754342; x=1769290342; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Iv3SD0WsKeyqpIbRwKokjasKKgiPm8GebeHbkz3lK3w=; b=bUfjYBqB92lxcvFYWO2EFGRpx9rclYnt3jpkzsfD574DTGH7FPzE3VXU SDfsc7Sbe1erc0QdpGKkTEUEWaLLYk4qC12BnmJzoVfqUX62jbZeu5ona qwjNejL3yuQMIHb4AgzSEsoRx39u046kj6fVFNjnHqMJut5HxxOOI5vo9 O3BTSOkj1NSzlWj4pyTWBxqleQmG/8I2+iSe0dT7XLgd9ayqopFCPqkjN G0bbu0s3G7CIhgl0XhTixklQ9HqbJK65P1WSqXBXwnoEPIivlATg8tJR8 tzZm4UWAjLWFtNLYdl0hOUhA6rzGRrCvm/LFIMYxGhHTjNNkDCGoUZ4Zd g==; X-CSE-ConnectionGUID: rX0JYwUqQHCcy6wWeJ8vOg== X-CSE-MsgGUID: R88Gy0TyR82Fv3NzExhcGw== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140402" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140402" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:17 -0800 X-CSE-ConnectionGUID: qpYqG4HuTUuvWlaUfD8JAw== X-CSE-MsgGUID: i0Y+RkvQRtGDgtsGhW+ZeA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861086" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:17 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Marco Leogrande , anthony.l.nguyen@intel.com, emil.s.tantilov@intel.com, anjali.singhai@intel.com, przemyslaw.kitszel@intel.com, sridhar.samudrala@intel.com, jacob.e.keller@intel.com, brianvv.kernel@gmail.com, decot@google.com, manojvishy@google.com, vivekmr@google.com, willemb@google.com, Brian Vazquez , Pavan Kumar Linga , Krishneil Singh Subject: [PATCH net 4/8] idpf: convert workqueues to unbound Date: Fri, 24 Jan 2025 13:32:06 -0800 Message-ID: <20250124213213.1328775-5-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Marco Leogrande When a workqueue is created with `WQ_UNBOUND`, its work items are served by special worker-pools, whose host workers are not bound to any specific CPU. In the default configuration (i.e. when `queue_delayed_work` and friends do not specify which CPU to run the work item on), `WQ_UNBOUND` allows the work item to be executed on any CPU in the same node of the CPU it was enqueued on. While this solution potentially sacrifices locality, it avoids contention with other processes that might dominate the CPU time of the processor the work item was scheduled on. This is not just a theoretical problem: in a particular scenario misconfigured process was hogging most of the time from CPU0, leaving less than 0.5% of its CPU time to the kworker. The IDPF workqueues that were using the kworker on CPU0 suffered large completion delays as a result, causing performance degradation, timeouts and eventual system crash. Tested: * I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This process is run under `taskset 01` to bind it to CPU0, and its priority is changed with `chrt -pQ 9900 10000 ${pid}` and `renice -n -20 ${pid}` after start. Then, the IDPF driver is forced to prefer CPU0 by editing all calls to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0. Finally, `ktraces` for the workqueue events are collected. Without the current patch, the antagonist process can force arbitrary delays between `workqueue_queue_work` and `workqueue_execute_start`, that in my tests were as high as `30ms`. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was `6us`. Fixes: 0fe45467a104 ("idpf: add create vport and netdev configuration") Signed-off-by: Marco Leogrande Signed-off-by: Manoj Vishwanathan Signed-off-by: Brian Vazquez Reviewed-by: Jacob Keller Reviewed-by: Pavan Kumar Linga Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_main.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_main.c b/drivers/net/ethernet/intel/idpf/idpf_main.c index f71d3182580b..b6c515d14cbf 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_main.c +++ b/drivers/net/ethernet/intel/idpf/idpf_main.c @@ -174,7 +174,8 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent) pci_set_master(pdev); pci_set_drvdata(pdev, adapter); - adapter->init_wq = alloc_workqueue("%s-%s-init", 0, 0, + adapter->init_wq = alloc_workqueue("%s-%s-init", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0, dev_driver_string(dev), dev_name(dev)); if (!adapter->init_wq) { @@ -183,7 +184,8 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent) goto err_free; } - adapter->serv_wq = alloc_workqueue("%s-%s-service", 0, 0, + adapter->serv_wq = alloc_workqueue("%s-%s-service", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0, dev_driver_string(dev), dev_name(dev)); if (!adapter->serv_wq) { @@ -192,7 +194,8 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent) goto err_serv_wq_alloc; } - adapter->mbx_wq = alloc_workqueue("%s-%s-mbx", 0, 0, + adapter->mbx_wq = alloc_workqueue("%s-%s-mbx", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0, dev_driver_string(dev), dev_name(dev)); if (!adapter->mbx_wq) { @@ -201,7 +204,8 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent) goto err_mbx_wq_alloc; } - adapter->stats_wq = alloc_workqueue("%s-%s-stats", 0, 0, + adapter->stats_wq = alloc_workqueue("%s-%s-stats", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0, dev_driver_string(dev), dev_name(dev)); if (!adapter->stats_wq) { @@ -210,7 +214,8 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent) goto err_stats_wq_alloc; } - adapter->vc_event_wq = alloc_workqueue("%s-%s-vc_event", 0, 0, + adapter->vc_event_wq = alloc_workqueue("%s-%s-vc_event", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0, dev_driver_string(dev), dev_name(dev)); if (!adapter->vc_event_wq) { From patchwork Fri Jan 24 21:32:07 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949940 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B2BD1E7C29 for ; Fri, 24 Jan 2025 21:32:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754343; cv=none; b=VTUmmqOXGvUkWFnCXky7/BpgQfc3bmfyJM7g4ENBnW7/x5u9vXFZ7SvNGS48zjUirGk7Nlck4fWVfX+ZlnuF+6yxK6c3kF3HYr6POK4oG53dOJSXsExHTchLPOf4mlL4ICWEDqB4rLIY0tDtsYC7DzD7FnGCQwEaz5esbi1KMws= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754343; c=relaxed/simple; bh=0ItajPF9ZBatRAHUnuKWBuQNpF/7DGmLcuDQEnkz/Cg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Uvxxp9IdLRlZBmXh8MW5LtiRpfcaOrN89Q6moJwakaE/SiyRSizLXu36lI2LfJH/2wCPSaOoSsbDZKTz+ae/Wzq2BI57faoYUIyMX9JtsF4wkXPOVM4KeeOS4fFoD2ID8+G1l9wYdJZfZn+KAaImx5Wnx1qc1aFYj5kR+GLSBwo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HtLI6/6I; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="HtLI6/6I" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754342; x=1769290342; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0ItajPF9ZBatRAHUnuKWBuQNpF/7DGmLcuDQEnkz/Cg=; b=HtLI6/6InDeXi50apKm36zqFMPkPPqTr1zMIDYMBCxAXxklKL8e966Ig qQVf/NnK7j4VATXnXW0V3VMofc13IocV7sL+k2/kQYNB7RgbJKnFi8kk2 dzTUeHZnrAGtVnOkAquU04CFyWPm6xi4U+MPKACqF2YZTxOk9BUW3qIT8 XYG2sjNBEEHlcSphID9qtVsLhvjuAByQQFVaCVQ5rioa6hwwvsQ5R3omQ sFDHSr2V0o78jkPkdXz9RSYWccJmNJIVpSnP723N2qTN9sJ3Aq6NWm7er 6Bv6KRJRam4kPVQ2CPpMkdb7P4rXCZjkzBVWImkXdeMYCX6+9dMe0iyKi w==; X-CSE-ConnectionGUID: y8qFMf2TTRmjZUhQOU2ggQ== X-CSE-MsgGUID: R5IedEOsTim62zOXczE3fg== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140410" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140410" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:18 -0800 X-CSE-ConnectionGUID: RTZxh76+TkOyLTgVVKsdbw== X-CSE-MsgGUID: tcBRWJmQRp6L7i8paTX3UQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861090" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:17 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Manoj Vishwanathan , anthony.l.nguyen@intel.com, emil.s.tantilov@intel.com, anjali.singhai@intel.com, przemyslaw.kitszel@intel.com, sridhar.samudrala@intel.com, jacob.e.keller@intel.com, pavan.kumar.linga@intel.com, brianvv.kernel@gmail.com, decot@google.com, pmenzel@molgen.mpg.de, vivekmr@google.com, Brian Vazquez , Krishneil Singh Subject: [PATCH net 5/8] idpf: add more info during virtchnl transaction timeout/salt mismatch Date: Fri, 24 Jan 2025 13:32:07 -0800 Message-ID: <20250124213213.1328775-6-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Manoj Vishwanathan Add more information related to the transaction like cookie, vc_op, salt when transaction times out and include similar information when transaction salt does not match. Info output for transaction timeout: ------------------- (op:5015 cookie:45fe vc_op:5015 salt:45 timeout:60000ms) ------------------- before it was: ------------------- (op 5015, 60000ms) ------------------- Signed-off-by: Manoj Vishwanathan Signed-off-by: Brian Vazquez Reviewed-by: Jacob Keller Reviewed-by: Pavan Kumar Linga Reviewed-by: Paul Menzel Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index 99bdb95bf226..3d2413b8684f 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c @@ -517,8 +517,10 @@ static ssize_t idpf_vc_xn_exec(struct idpf_adapter *adapter, retval = -ENXIO; goto only_unlock; case IDPF_VC_XN_WAITING: - dev_notice_ratelimited(&adapter->pdev->dev, "Transaction timed-out (op %d, %dms)\n", - params->vc_op, params->timeout_ms); + dev_notice_ratelimited(&adapter->pdev->dev, + "Transaction timed-out (op:%d cookie:%04x vc_op:%d salt:%02x timeout:%dms)\n", + params->vc_op, cookie, xn->vc_op, + xn->salt, params->timeout_ms); retval = -ETIME; break; case IDPF_VC_XN_COMPLETED_SUCCESS: @@ -615,8 +617,9 @@ idpf_vc_xn_forward_reply(struct idpf_adapter *adapter, idpf_vc_xn_lock(xn); salt = FIELD_GET(IDPF_VC_XN_SALT_M, msg_info); if (xn->salt != salt) { - dev_err_ratelimited(&adapter->pdev->dev, "Transaction salt does not match (%02x != %02x)\n", - xn->salt, salt); + dev_err_ratelimited(&adapter->pdev->dev, "Transaction salt does not match (exp:%d@%02x(%d) != got:%d@%02x)\n", + xn->vc_op, xn->salt, xn->state, + ctlq_msg->cookie.mbx.chnl_opcode, salt); idpf_vc_xn_unlock(xn); return -EINVAL; } From patchwork Fri Jan 24 21:32:08 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949941 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFA0F1E7C38 for ; Fri, 24 Jan 2025 21:32:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754344; cv=none; b=WpTaXAWEKG2qukokvdPRYg1+ilkHGlr5ulCJFLoiSRuTq2jT2Quvv1mC+uO+GZGWddG6OQlBlBpy6nOXdrjGaxflmNzfGayl+2pXfnbChhXqqr4PdneBGgr0cvZJdjXCWHnGmfGWH0plJEvADBrHMcHSTf2TKboCsLFu2/HBxUw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754344; c=relaxed/simple; bh=RLST+wEvPIdxiVmJ7UkI5OXguXZfGshIONW1OgmGTV0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bi/t8+uxDKoBT2HTBLTHvgGKmrWksbTPE6QhViC6XDwDcIZp5dW3Tn8rsXgRJ+K2//xrQniZNePRR2+KW3HFta3HituOXjiAHqSUY1azE3vEovKCtf/KU/kHQyMMy7OGNstQvBj3bnjnB+fAxSzW3D9MwA1V9ddjFODzbbErWwk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JSMTvdt4; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JSMTvdt4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754343; x=1769290343; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=RLST+wEvPIdxiVmJ7UkI5OXguXZfGshIONW1OgmGTV0=; b=JSMTvdt4ExW/WNVSgHSZoxjqAjQv5Wte19bGqGH22Zo16RrQTTFTI43r l1dk9uUDJXdD03VDfqYxMfoBwqCoBMPm22zziViDb6jSBPClNAjBcL7SG xpNr8EZ0sVxSBmzICK63iE3zUXgfqaqKcc9IVEfdeSS0PZ1+I+MZy7D8a BWkW2TT/WSvNuQBlw0Z6CRBpVbK/ORANKo+JW8/wT6jfyxwj8OmYLv1AG 14IhxUmfiYiFh6U1SJzHOx1pBlJoPiGKMW6oem/oJ8G/eUykA9M+ymqNm VMgjpaf9tghEngN/HZ96yTyD8g6xDLjZHGf0iCR1KHtHDJ2OFJy37tcvV w==; X-CSE-ConnectionGUID: dhP+uLxRSn6MscNBLgnIEQ== X-CSE-MsgGUID: Ab/M8cEbQ0ekHu/iXcKnQg== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140418" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140418" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:18 -0800 X-CSE-ConnectionGUID: +8+X94HLQ8GZIyYdPaITew== X-CSE-MsgGUID: ICfJQTjlQaeBrsbIoe4WaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861093" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:17 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Przemek Kitszel , anthony.l.nguyen@intel.com, horms@kernel.org, larysa.zaremba@intel.com, dan.carpenter@linaro.org, Ahmed Zaki , Rafal Romanowski Subject: [PATCH net 6/8] ice: fix ice_parser_rt::bst_key array size Date: Fri, 24 Jan 2025 13:32:08 -0800 Message-ID: <20250124213213.1328775-7-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Przemek Kitszel Fix &ice_parser_rt::bst_key size. It was wrongly set to 10 instead of 20 in the initial impl commit (see Fixes tag). All usage code assumed it was of size 20. That was also the initial size present up to v2 of the intro series [2], but halved by v3 [3] refactor described as "Replace magic hardcoded values with macros." The introducing series was so big that some ugliness was unnoticed, same for bugs :/ ICE_BST_KEY_TCAM_SIZE and ICE_BST_TCAM_KEY_SIZE were differing by one. There was tmp variable @j in the scope of edited function, but was not used in all places. This ugliness is now gone. I'm moving ice_parser_rt::pg_prio a few positions up, to fill up one of the holes in order to compensate for the added 10 bytes to the ::bst_key, resulting in the same size of the whole as prior to the fix, and minimal changes in the offsets of the fields. Extend also the debug dump print of the key to cover all bytes. To not have string with 20 "%02x" and 20 params, switch to ice_debug_array_w_prefix(). This fix obsoletes Ahmed's attempt at [1]. [1] https://lore.kernel.org/intel-wired-lan/20240823230847.172295-1-ahmed.zaki@intel.com [2] https://lore.kernel.org/intel-wired-lan/20230605054641.2865142-13-junfeng.guo@intel.com [3] https://lore.kernel.org/intel-wired-lan/20230817093442.2576997-13-junfeng.guo@intel.com Reported-by: Dan Carpenter Closes: https://lore.kernel.org/intel-wired-lan/b1fb6ff9-b69e-4026-9988-3c783d86c2e0@stanley.mountain Fixes: 9a4c07aaa0f5 ("ice: add parser execution main loop") CC: Ahmed Zaki Reviewed-by: Larysa Zaremba Signed-off-by: Przemek Kitszel Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_parser.h | 6 ++---- drivers/net/ethernet/intel/ice/ice_parser_rt.c | 12 +++++------- 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_parser.h b/drivers/net/ethernet/intel/ice/ice_parser.h index 6509d807627c..4f56d53d56b9 100644 --- a/drivers/net/ethernet/intel/ice/ice_parser.h +++ b/drivers/net/ethernet/intel/ice/ice_parser.h @@ -257,7 +257,6 @@ ice_pg_nm_cam_match(struct ice_pg_nm_cam_item *table, int size, /*** ICE_SID_RXPARSER_BOOST_TCAM and ICE_SID_LBL_RXPARSER_TMEM sections ***/ #define ICE_BST_TCAM_TABLE_SIZE 256 #define ICE_BST_TCAM_KEY_SIZE 20 -#define ICE_BST_KEY_TCAM_SIZE 19 /* Boost TCAM item */ struct ice_bst_tcam_item { @@ -401,7 +400,6 @@ u16 ice_xlt_kb_flag_get(struct ice_xlt_kb *kb, u64 pkt_flag); #define ICE_PARSER_GPR_NUM 128 #define ICE_PARSER_FLG_NUM 64 #define ICE_PARSER_ERR_NUM 16 -#define ICE_BST_KEY_SIZE 10 #define ICE_MARKER_ID_SIZE 9 #define ICE_MARKER_MAX_SIZE \ (ICE_MARKER_ID_SIZE * BITS_PER_BYTE - 1) @@ -431,13 +429,13 @@ struct ice_parser_rt { u8 pkt_buf[ICE_PARSER_MAX_PKT_LEN + ICE_PARSER_PKT_REV]; u16 pkt_len; u16 po; - u8 bst_key[ICE_BST_KEY_SIZE]; + u8 bst_key[ICE_BST_TCAM_KEY_SIZE]; struct ice_pg_cam_key pg_key; + u8 pg_prio; struct ice_alu *alu0; struct ice_alu *alu1; struct ice_alu *alu2; struct ice_pg_cam_action *action; - u8 pg_prio; struct ice_gpr_pu pu; u8 markers[ICE_MARKER_ID_SIZE]; bool protocols[ICE_PO_PAIR_SIZE]; diff --git a/drivers/net/ethernet/intel/ice/ice_parser_rt.c b/drivers/net/ethernet/intel/ice/ice_parser_rt.c index dedf5e854e4b..3995d662e050 100644 --- a/drivers/net/ethernet/intel/ice/ice_parser_rt.c +++ b/drivers/net/ethernet/intel/ice/ice_parser_rt.c @@ -125,22 +125,20 @@ static void ice_bst_key_init(struct ice_parser_rt *rt, else key[idd] = imem->b_kb.prio; - idd = ICE_BST_KEY_TCAM_SIZE - 1; + idd = ICE_BST_TCAM_KEY_SIZE - 2; for (i = idd; i >= 0; i--) { int j; j = ho + idd - i; if (j < ICE_PARSER_MAX_PKT_LEN) - key[i] = rt->pkt_buf[ho + idd - i]; + key[i] = rt->pkt_buf[j]; else key[i] = 0; } - ice_debug(rt->psr->hw, ICE_DBG_PARSER, "Generated Boost TCAM Key:\n"); - ice_debug(rt->psr->hw, ICE_DBG_PARSER, "%02X %02X %02X %02X %02X %02X %02X %02X %02X %02X\n", - key[0], key[1], key[2], key[3], key[4], - key[5], key[6], key[7], key[8], key[9]); - ice_debug(rt->psr->hw, ICE_DBG_PARSER, "\n"); + ice_debug_array_w_prefix(rt->psr->hw, ICE_DBG_PARSER, + KBUILD_MODNAME ": Generated Boost TCAM Key", + key, ICE_BST_TCAM_KEY_SIZE); } static u16 ice_bit_rev_u16(u16 v, int len) From patchwork Fri Jan 24 21:32:09 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949942 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04AE61E98FC for ; Fri, 24 Jan 2025 21:32:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754345; cv=none; b=H3ut60alyoSFK02ydPzIeuV7ycsdWk+UFa3dE7Rkk/I+m3TlvyQxA7tDfh7OxZlo2ovgR5mormOhQTCGzGn45RrF/U0rgwdqk32mI2MexLYF7TY/AF+oOjG5f7ySd89ZmzCNvpo4zZQ7cu4pr+yed78+trfIAOOVkNIzjswEInk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754345; c=relaxed/simple; bh=ZrV+XyRuM02A4ZzGb2Qkos38j0RdBLVlDnc5T18iG6w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LVOobaMmdl9UVF/ilzeV4HYbENEET5VIRS9gQB5pA58sV/uD+bjPQNSVFW2fKybbc60ViX+3oh0x5lPWOru/4TaAuc7FR/Uj4G3UW9HqXElWrM/F2x5Vby33YD9YVj1y4klka5/CNpZZX68CEv0PqSBX5WnlXz6pWKg/2OaVbNY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=KegWzRqb; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="KegWzRqb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754344; x=1769290344; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ZrV+XyRuM02A4ZzGb2Qkos38j0RdBLVlDnc5T18iG6w=; b=KegWzRqb+rMLsVU1Srw9SLXnxpLE81PeSTWLN9IdQEDt5jAUUQTFxCby sIVkE+Nz64aq8XQMvwyLElnt1ixSP6wDWLhgsDh/Fm8cl1zqvl8BNiXBT 7ik1O8lTcOw8DJB5HD685x0L16DK80PrHEeUDdXcFKWzmLVXR3LP5i17P eLpzMrgkuGCSXsCLeidgVho5pQWZjygsJsA9VmPKsMxXBggXTzsOC3SxA kdfsjjQGptWTjAVV5t8NjgIjfzqXjA0i70VY+72+eOrSri48l9Xo6oga8 o7f7KtBaH3Os6x72xIo+7Mw3/ihuvoGzfLu7AwohQ9c97x243C8JEJFac Q==; X-CSE-ConnectionGUID: WvU6E5rcQNOHTAllwMWlww== X-CSE-MsgGUID: 4HEZhcJSSvCowBTvVoJdWQ== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140424" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140424" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:18 -0800 X-CSE-ConnectionGUID: yDYGrgq6ScOsMdSGmCiEKw== X-CSE-MsgGUID: lgfVZouoQES3Moyw+7e02Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861096" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:17 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Mateusz Polchlopek , anthony.l.nguyen@intel.com, horms@kernel.org, Michal Swiatkowski , Rinitha S Subject: [PATCH net 7/8] ice: remove invalid parameter of equalizer Date: Fri, 24 Jan 2025 13:32:09 -0800 Message-ID: <20250124213213.1328775-8-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Mateusz Polchlopek It occurred that in the commit 70838938e89c ("ice: Implement driver functionality to dump serdes equalizer values") the invalid DRATE parameter for reading has been added. The output of the command: $ ethtool -d returns the garbage value in the place where DRATE value should be stored. Remove mentioned parameter to prevent return of corrupted data to userspace. Fixes: 70838938e89c ("ice: Implement driver functionality to dump serdes equalizer values") Signed-off-by: Mateusz Polchlopek Reviewed-by: Michal Swiatkowski Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 1 - drivers/net/ethernet/intel/ice/ice_ethtool.c | 1 - drivers/net/ethernet/intel/ice/ice_ethtool.h | 1 - 3 files changed, 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h index 01536a382e54..bdee499f991a 100644 --- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h +++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h @@ -1498,7 +1498,6 @@ struct ice_aqc_dnl_equa_param { #define ICE_AQC_RX_EQU_POST1 (0x12 << ICE_AQC_RX_EQU_SHIFT) #define ICE_AQC_RX_EQU_BFLF (0x13 << ICE_AQC_RX_EQU_SHIFT) #define ICE_AQC_RX_EQU_BFHF (0x14 << ICE_AQC_RX_EQU_SHIFT) -#define ICE_AQC_RX_EQU_DRATE (0x15 << ICE_AQC_RX_EQU_SHIFT) #define ICE_AQC_RX_EQU_CTLE_GAINHF (0x20 << ICE_AQC_RX_EQU_SHIFT) #define ICE_AQC_RX_EQU_CTLE_GAINLF (0x21 << ICE_AQC_RX_EQU_SHIFT) #define ICE_AQC_RX_EQU_CTLE_GAINDC (0x22 << ICE_AQC_RX_EQU_SHIFT) diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c index 3072634bf049..f241493a6ac8 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c @@ -710,7 +710,6 @@ static int ice_get_tx_rx_equa(struct ice_hw *hw, u8 serdes_num, { ICE_AQC_RX_EQU_POST1, rx, &ptr->rx_equ_post1 }, { ICE_AQC_RX_EQU_BFLF, rx, &ptr->rx_equ_bflf }, { ICE_AQC_RX_EQU_BFHF, rx, &ptr->rx_equ_bfhf }, - { ICE_AQC_RX_EQU_DRATE, rx, &ptr->rx_equ_drate }, { ICE_AQC_RX_EQU_CTLE_GAINHF, rx, &ptr->rx_equ_ctle_gainhf }, { ICE_AQC_RX_EQU_CTLE_GAINLF, rx, &ptr->rx_equ_ctle_gainlf }, { ICE_AQC_RX_EQU_CTLE_GAINDC, rx, &ptr->rx_equ_ctle_gaindc }, diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.h b/drivers/net/ethernet/intel/ice/ice_ethtool.h index 8f2ad1c172c0..23b2cfbc9684 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.h +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.h @@ -15,7 +15,6 @@ struct ice_serdes_equalization_to_ethtool { int rx_equ_post1; int rx_equ_bflf; int rx_equ_bfhf; - int rx_equ_drate; int rx_equ_ctle_gainhf; int rx_equ_ctle_gainlf; int rx_equ_ctle_gaindc; From patchwork Fri Jan 24 21:32:10 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13949943 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C4CE1E98FD for ; Fri, 24 Jan 2025 21:32:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754345; cv=none; b=FyAjZprKwM2CsE64ectnjp5GerK8NRO+IcVg7r3wBS/Y9oe8N2jPec1ijkIUraY4k3E2U485SefOAwgrdyZuMsvpVDC/WGCln1Zt7w88lijuKxivKxXHRo2hmpgo0Rv4stKWsSwN9hDtTAJK73QzybbPfWFSvP1qBVre/0NOp6c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737754345; c=relaxed/simple; bh=H8nOM7SSy24Jz13dsHfv/Pc3sazm6NLngjfMS12J8n4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lGcHGt2JwA0nQ2P1hMvdypWBpXrYNDqtK5ml1pp8TSdzJHK7FfU0Y3dtPFyV+15JMvBKeOSLg1maO8vZZZ3HuocY66/CRsPYhydpu3fS8IdfFde2A6p+dxQ8mn9fUDiQKlNLT/VKkcb2QGGF692qDozIRjgoqI/psqbVGmH7/PI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EXuJXbq1; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EXuJXbq1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737754344; x=1769290344; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=H8nOM7SSy24Jz13dsHfv/Pc3sazm6NLngjfMS12J8n4=; b=EXuJXbq1XSNI0SEkYehfgnop+mtpbfKTRInQEntJATZ2vM5bxVfIFWLL t+XjXrVsI4ZRvcp7R9sJcHRCglhUDV5sVsmcPHubCgsSeeTprPiPpdWhE kNZNW4i3uyeLZMxPVDwfAWG9j5ETsT9W5c0r8bwHzK+cSLer3cctJcPJT HCehVldAwxiS1tJveSO6+7g+H/08atT4DoKaW7wBqcXC3fHwmbG5LWTKD bczPXk82nhK+jQLiFuIYKkjZo6cjvrMfEg1ydwHPmn/k+KJMvdgPRHC6c ZGB9SuNhA91Z9hMP5G9horzUaEcSq2RgrPJalzVItudeobU9VUwTEPRZL g==; X-CSE-ConnectionGUID: app9tB01TrOwjN2mI4svzg== X-CSE-MsgGUID: fPnc8g2nTrWWvVnP+gpbSw== X-IronPort-AV: E=McAfee;i="6700,10204,11325"; a="41140429" X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="41140429" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2025 13:32:18 -0800 X-CSE-ConnectionGUID: FcZtJZDLQVSbBLLJmm7FGw== X-CSE-MsgGUID: Myn2BTtRQCmCOpLNVhjK8A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,232,1732608000"; d="scan'208";a="107861099" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa006.jf.intel.com with ESMTP; 24 Jan 2025 13:32:18 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Michal Swiatkowski , anthony.l.nguyen@intel.com, Przemek Kitszel , Rafal Romanowski Subject: [PATCH net 8/8] iavf: allow changing VLAN state without calling PF Date: Fri, 24 Jan 2025 13:32:10 -0800 Message-ID: <20250124213213.1328775-9-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> References: <20250124213213.1328775-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Michal Swiatkowski First case: > ip l a l $VF name vlanx type vlan id 100 > ip l d vlanx > ip l a l $VF name vlanx type vlan id 100 As workqueue can be execute after sometime, there is a window to have call trace like that: - iavf_del_vlan - iavf_add_vlan - iavf_del_vlans (wq) It means that our VLAN 100 will change the state from IAVF_VLAN_ACTIVE to IAVF_VLAN_REMOVE (iavf_del_vlan). After that in iavf_add_vlan state won't be changed because VLAN 100 is on the filter list. The final result is that the VLAN 100 filter isn't added in hardware (no iavf_add_vlans call). To fix that change the state if the filter wasn't removed yet directly to active. It is save as IAVF_VLAN_REMOVE means that virtchnl message wasn't sent yet. Second case: > ip l a l $VF name vlanx type vlan id 100 Any type of VF reset ex. change trust > ip l s $PF vf $VF_NUM trust on > ip l d vlanx > ip l a l $VF name vlanx type vlan id 100 In case of reset iavf driver is responsible for readding all filters that are being used. To do that all VLAN filters state are changed to IAVF_VLAN_ADD. Here is even longer window for changing VLAN state from kernel side, as workqueue isn't called immediately. We can have call trace like that: - changing to IAVF_VLAN_ADD (after reset) - iavf_del_vlan (called from kernel ops) - iavf_del_vlans (wq) Not exsisitng VLAN filters will be removed from hardware. It isn't a bug, ice driver will handle it fine. However, we can have call trace like that: - changing to IAVF_VLAN_ADD (after reset) - iavf_del_vlan (called from kernel ops) - iavf_add_vlan (called from kernel ops) - iavf_del_vlans (wq) With fix for previous case we end up with no VLAN filters in hardware. We have to remove VLAN filters if the state is IAVF_VLAN_ADD and delete VLAN was called. It is save as IAVF_VLAN_ADD means that virtchnl message wasn't sent yet. Fixes: 0c0da0e95105 ("iavf: refactor VLAN filter states") Signed-off-by: Michal Swiatkowski Reviewed-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/iavf/iavf_main.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c index cbfaaa5b7d02..2d7a18fcc3be 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_main.c +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c @@ -773,6 +773,11 @@ iavf_vlan_filter *iavf_add_vlan(struct iavf_adapter *adapter, f->state = IAVF_VLAN_ADD; adapter->num_vlan_filters++; iavf_schedule_aq_request(adapter, IAVF_FLAG_AQ_ADD_VLAN_FILTER); + } else if (f->state == IAVF_VLAN_REMOVE) { + /* IAVF_VLAN_REMOVE means that VLAN wasn't yet removed. + * We can safely only change the state here. + */ + f->state = IAVF_VLAN_ACTIVE; } clearout: @@ -793,8 +798,18 @@ static void iavf_del_vlan(struct iavf_adapter *adapter, struct iavf_vlan vlan) f = iavf_find_vlan(adapter, vlan); if (f) { - f->state = IAVF_VLAN_REMOVE; - iavf_schedule_aq_request(adapter, IAVF_FLAG_AQ_DEL_VLAN_FILTER); + /* IAVF_ADD_VLAN means that VLAN wasn't even added yet. + * Remove it from the list. + */ + if (f->state == IAVF_VLAN_ADD) { + list_del(&f->list); + kfree(f); + adapter->num_vlan_filters--; + } else { + f->state = IAVF_VLAN_REMOVE; + iavf_schedule_aq_request(adapter, + IAVF_FLAG_AQ_DEL_VLAN_FILTER); + } } spin_unlock_bh(&adapter->mac_vlan_list_lock);