From patchwork Mon Sep 9 20:38:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13797569 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 2A33118B464 for ; Mon, 9 Sep 2024 20:39:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914347; cv=none; b=FEDdba6T63oEHEwmbj3am0e42nUhC0JnNO6N9+1Wn/Z8YdFfxqggfmgkl+u2+cWoucu0oTO69ElZFhto5an6RUGCx6frf34TEsDjSS0kR/eKQknOOZwL7nwKVGrgm7Id42dFrqpRZMrXIaHnBHTzW4dxjuq5lbndTZfbOCme574= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914347; c=relaxed/simple; bh=l9YWFyi3pWxAoa7A/Jm+BQ7HKUCTnOhEJXioDIDl2hs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=b0f7NgGs5jBq3Tgnlz/Xx4UkKytk0XYVxar8uNguR4AfcyXdFzJIxqQfQvlPU4rVasp50TrP3016TWty8roQCTxsZgGQgMM7u2NpOavjC+SC1GudGK7tc6gEY28qk9FcXkwl/FZlxk5tRaMOklknRTHCBC/STAP15R6ae21Erx4= 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=AGcZPc2K; arc=none smtp.client-ip=198.175.65.17 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="AGcZPc2K" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725914345; x=1757450345; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=l9YWFyi3pWxAoa7A/Jm+BQ7HKUCTnOhEJXioDIDl2hs=; b=AGcZPc2KutCiPsBJwim4oykgHFAmOaqh851vDmIzL4o4ZJNNsdiRtq/r w+3FbXGMVOYJTWaOJAzteDFdSPeWxbCShiWOcczsJZ+QGbiJkdm3/i2Q3 w1eUjhhlelI3vC6n0hPTouO99xieP6rD3lRygL7LvTc4hvA9AiR+Q/U1n Jj1yTywlZXqJY9ax61KVSEalpl5NGjRiNxY50xOsp7s3czIKbwFMMA04l oWn82Kqs7qRHJZjItKireN8vIUvff7zLdAYMX4K9zP0WiTdNBjiDMaE6U EgfMdDdCuXKKbjvZaVmYuKrsiZsqM+Rplt8yXMXfyEj9kmWzZMEyNzB79 A==; X-CSE-ConnectionGUID: AbkNAroBQMyod3gnsVA3LQ== X-CSE-MsgGUID: v8mbKBejRpSunykh0xpYPQ== X-IronPort-AV: E=McAfee;i="6700,10204,11190"; a="24787101" X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="24787101" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 13:39:00 -0700 X-CSE-ConnectionGUID: jqdHGkMJT4iRgrxs4ZA+cg== X-CSE-MsgGUID: nAgUUdmHSSSqSfXQqhMyJQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="67054807" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa010.fm.intel.com with ESMTP; 09 Sep 2024 13:38:50 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Martyna Szapar-Mudlaw , anthony.l.nguyen@intel.com, =?utf-8?b?TWF0xJtqIEdyw6lncg==?= , Przemek Kitszel , Pucha Himasekhar Reddy Subject: [PATCH net 1/5] ice: Fix lldp packets dropping after changing the number of channels Date: Mon, 9 Sep 2024 13:38:37 -0700 Message-ID: <20240909203842.3109822-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240909203842.3109822-1-anthony.l.nguyen@intel.com> References: <20240909203842.3109822-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: Martyna Szapar-Mudlaw After vsi setup refactor commit 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") ice_cfg_sw_lldp function which removes rx rule directing LLDP packets to vsi is moved from ice_vsi_release to ice_vsi_decfg function. ice_vsi_decfg is used in more cases than just in vsi_release resulting in unnecessary removal of rx lldp packets handling switch rule. This leads to lldp packets being dropped after a change number of channels via ethtool. This patch moves ice_cfg_sw_lldp function that removes rx lldp sw rule back to ice_vsi_release function. Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") Reported-by: Matěj Grégr Closes: https://lore.kernel.org/intel-wired-lan/1be45a76-90af-4813-824f-8398b69745a9@netx.as/T/#u Reviewed-by: Przemek Kitszel Signed-off-by: Martyna Szapar-Mudlaw Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_lib.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c index 737c00b02dd0..2405e5ed9128 100644 --- a/drivers/net/ethernet/intel/ice/ice_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_lib.c @@ -2413,13 +2413,6 @@ void ice_vsi_decfg(struct ice_vsi *vsi) struct ice_pf *pf = vsi->back; int err; - /* The Rx rule will only exist to remove if the LLDP FW - * engine is currently stopped - */ - if (!ice_is_safe_mode(pf) && vsi->type == ICE_VSI_PF && - !test_bit(ICE_FLAG_FW_LLDP_AGENT, pf->flags)) - ice_cfg_sw_lldp(vsi, false, false); - ice_rm_vsi_lan_cfg(vsi->port_info, vsi->idx); err = ice_rm_vsi_rdma_cfg(vsi->port_info, vsi->idx); if (err) @@ -2764,6 +2757,14 @@ int ice_vsi_release(struct ice_vsi *vsi) ice_rss_clean(vsi); ice_vsi_close(vsi); + + /* The Rx rule will only exist to remove if the LLDP FW + * engine is currently stopped + */ + if (!ice_is_safe_mode(pf) && vsi->type == ICE_VSI_PF && + !test_bit(ICE_FLAG_FW_LLDP_AGENT, pf->flags)) + ice_cfg_sw_lldp(vsi, false, false); + ice_vsi_decfg(vsi); /* retain SW VSI data structure since it is needed to unregister and From patchwork Mon Sep 9 20:38:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13797570 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 5BC1018B470 for ; Mon, 9 Sep 2024 20:39:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914349; cv=none; b=XAg3BP1mOJyjeoq6EbzwDOeUH/z0UqwgyxKWy+dZ0R0YncHhwMfCN/m9NtAoJd/XQhRU5msOfacna3RlGhes6yVHQD5jpdrZkeh3LL30HYo8SNkLVE0aZphf0FXsJZb2Gfq+xVdHRrLWQi9CYhxke9PJFDbIAAk7Jws1lwFfu/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914349; c=relaxed/simple; bh=x/qZRdIfOf+Q27rpWJRGHLZJxuyAjmLn0ITLU+YUE2I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lhqqaPZGkf4uZTHwWB0OLMyRStvz/o2CLWvDkZSubQ0igemoKnuAN38q/WTw/3kGrcDLjTlmWiTFrUAOD3TE21pAepWJ7of6yD1XMQhtkF0A1Ku9yhrU7iEsRlVkg/vsC2ne8Uuq+w/RFdyNzEOHGFckYD398Qudd1knexzflGw= 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=h7mfcWbb; arc=none smtp.client-ip=198.175.65.17 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="h7mfcWbb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725914347; x=1757450347; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=x/qZRdIfOf+Q27rpWJRGHLZJxuyAjmLn0ITLU+YUE2I=; b=h7mfcWbbq9UrpjGXEqBczVbpyevW0IW38ayM6lPAL35faDT8g776hc2y YTgAxQu1iJ5xRw4S6BMomLJnJ5IDVpaZubLab9giztA/2sA22VfWwlVkX PDviVQNq04Ck8IJxUC4YurljrC+PbM1y//duDLkdmwHVsEOJ91RexgyG8 hYo74ZFDgdjSyoIqa1c5kMq+iac0RLF1r20SA3tP2I9QaxESLQWxv7uUA DMRNMynUYoCE7k1E7q/yVdLxffKkKGY28V4tZbrUIga8GDj2f1POgyu+W 9wf6MO/9BdPlUWoErKAPqk8qwlq7xVC3nSDH905OT6ZVBHJnI79a05DII w==; X-CSE-ConnectionGUID: ss6v52pMQnmv1lrxoraW0g== X-CSE-MsgGUID: 6J9b2g3URha6Nn5GztgB6g== X-IronPort-AV: E=McAfee;i="6700,10204,11190"; a="24787112" X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="24787112" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 13:39:01 -0700 X-CSE-ConnectionGUID: NZZ5NnffRV2M4DQ2iiLN5g== X-CSE-MsgGUID: DTNamRvxTGyhlaoZsDHeXA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="67054812" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa010.fm.intel.com with ESMTP; 09 Sep 2024 13:38:50 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Jacob Keller , anthony.l.nguyen@intel.com, Rafal Romanowski Subject: [PATCH net 2/5] ice: fix accounting for filters shared by multiple VSIs Date: Mon, 9 Sep 2024 13:38:38 -0700 Message-ID: <20240909203842.3109822-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240909203842.3109822-1-anthony.l.nguyen@intel.com> References: <20240909203842.3109822-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: Jacob Keller When adding a switch filter (such as a MAC or VLAN filter), it is expected that the driver will detect the case where the filter already exists, and return -EEXIST. This is used by calling code such as ice_vc_add_mac_addr, and ice_vsi_add_vlan to avoid incrementing the accounting fields such as vsi->num_vlan or vf->num_mac. This logic works correctly for the case where only a single VSI has added a given switch filter. When a second VSI adds the same switch filter, the driver converts the existing filter from an ICE_FWD_TO_VSI filter into an ICE_FWD_TO_VSI_LIST filter. This saves switch resources, by ensuring that multiple VSIs can re-use the same filter. The ice_add_update_vsi_list() function is responsible for doing this conversion. When first converting a filter from the FWD_TO_VSI into FWD_TO_VSI_LIST, it checks if the VSI being added is the same as the existing rule's VSI. In such a case it returns -EEXIST. However, when the switch rule has already been converted to a FWD_TO_VSI_LIST, the logic is different. Adding a new VSI in this case just requires extending the VSI list entry. The logic for checking if the rule already exists in this case returns 0 instead of -EEXIST. This breaks the accounting logic mentioned above, so the counters for how many MAC and VLAN filters exist for a given VF or VSI no longer accurately reflect the actual count. This breaks other code which relies on these counts. In typical usage this primarily affects such filters generally shared by multiple VSIs such as VLAN 0, or broadcast and multicast MAC addresses. Fix this by correctly reporting -EEXIST in the case of adding the same VSI to a switch rule already converted to ICE_FWD_TO_VSI_LIST. Fixes: 9daf8208dd4d ("ice: Add support for switch filter programming") Signed-off-by: Jacob Keller Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_switch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index fe8847184cb1..0160f0bae8d6 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -3194,7 +3194,7 @@ ice_add_update_vsi_list(struct ice_hw *hw, /* A rule already exists with the new VSI being added */ if (test_bit(vsi_handle, m_entry->vsi_list_info->vsi_map)) - return 0; + return -EEXIST; /* Update the previously created VSI list set with * the new VSI ID passed in From patchwork Mon Sep 9 20:38:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13797571 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 41BD118B46D for ; Mon, 9 Sep 2024 20:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914350; cv=none; b=rkSelekU0pdcdQbZFsubVhYRLKBNEPTKkbhnliiAICEkbnma4oCazo9rNqCEdE8pO3aA7yZCrbOiowSG4Q8AtzCuSp7DO4zxuiQL/RfvVC2jcXCx6N6c+2CXS6Eq21tP4VwppyaUf5U4OY4ERuPtvuVlA6avig117w+usFWmhXg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914350; c=relaxed/simple; bh=aYmd3+COS+USN9mmcTDE7li6X29cDuYrVazlIQ+pBPc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LcKrUDVJP3Rc0NXflX81HaOgW17xZmAmGDSorv04m1Ljgbu64WF5qXSKUq5yP6RKPya65ROKEFIVboEMssAnG3RYaw3noq7g/xepChnSIQ5Za17QMST6n5h7DGNdh5qszDgnClWdwLlikf6T8UHQ+3c60d47rypDjAS7ek8xZw4= 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=LiMjjxiH; arc=none smtp.client-ip=198.175.65.17 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="LiMjjxiH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725914349; x=1757450349; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aYmd3+COS+USN9mmcTDE7li6X29cDuYrVazlIQ+pBPc=; b=LiMjjxiHuIMJArZL/QSnYJACzo+1ZwiQuANRFBHPbSna7lLq9WdogoT9 57ouFP2bw+JnNgnhOc8vKH5mAUkxr9CaBOv4iw4vR69g+sMrjKinC+jae 8K9YbUKvwxO2X8ws9bQtPDA0W9p4c1DSTrPbpzM0RKTPnjhxkwWRZ4UUv IsfEsJGPjz0g9pUClTf8TvTSNcJEC8cZTf46aDfk0QYY878YaV/l/CdtF zvtOR+XV/ueTZNhGtkPw/9zhOca01D4EPO7TmOeT/IiRGPQ+1LUzQ0hDb pFTvx0M6h9+CUqDyd+Zgz6SbDDfDBscK1sK52SQSI+Om8SJtRYFYqLOPa g==; X-CSE-ConnectionGUID: 7Hd0XHTuQ5KZLWssIDWHrg== X-CSE-MsgGUID: QlGvy81AT+6pzhO6xb1ijQ== X-IronPort-AV: E=McAfee;i="6700,10204,11190"; a="24787132" X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="24787132" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 13:39:01 -0700 X-CSE-ConnectionGUID: I0+ucAqlTASJ64Fllsgmqw== X-CSE-MsgGUID: Ocq1oOSkQI6I4rBb6K1J4A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="67054816" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa010.fm.intel.com with ESMTP; 09 Sep 2024 13:38:50 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Przemek Kitszel , anthony.l.nguyen@intel.com, kwilczynski@kernel.org, bhelgaas@google.com, pstanner@redhat.com, Larysa Zaremba , Pucha Himasekhar Reddy Subject: [PATCH net 3/5] ice: stop calling pci_disable_device() as we use pcim Date: Mon, 9 Sep 2024 13:38:39 -0700 Message-ID: <20240909203842.3109822-4-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240909203842.3109822-1-anthony.l.nguyen@intel.com> References: <20240909203842.3109822-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 Our driver uses devres to manage resources, in particular we call pcim_enable_device(), what also means we express the intent to get automatic pci_disable_device() call at driver removal. Manual calls to pci_disable_device() misuse the API. Recent commit (see "Fixes" tag) has changed the removal action from conditional (silent ignore of double call to pci_disable_device()) to unconditional, but able to catch unwanted redundant calls; see cited "Fixes" commit for details. Since that, unloading the driver yields following warn+splat: [70633.628490] ice 0000:af:00.7: disabling already-disabled device [70633.628512] WARNING: CPU: 52 PID: 33890 at drivers/pci/pci.c:2250 pci_disable_device+0xf4/0x100 ... [70633.628744] ? pci_disable_device+0xf4/0x100 [70633.628752] release_nodes+0x4a/0x70 [70633.628759] devres_release_all+0x8b/0xc0 [70633.628768] device_unbind_cleanup+0xe/0x70 [70633.628774] device_release_driver_internal+0x208/0x250 [70633.628781] driver_detach+0x47/0x90 [70633.628786] bus_remove_driver+0x80/0x100 [70633.628791] pci_unregister_driver+0x2a/0xb0 [70633.628799] ice_module_exit+0x11/0x3a [ice] Note that this is the only Intel ethernet driver that needs such fix. Fixes: f748a07a0b64 ("PCI: Remove legacy pcim_release()") Reviewed-by: Larysa Zaremba Reviewed-by: Philipp Stanner Signed-off-by: Przemek Kitszel Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index c7db88b517da..ea780d468579 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -5363,7 +5363,6 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent) ice_deinit(pf); err_init: ice_adapter_put(pdev); - pci_disable_device(pdev); return err; } @@ -5470,7 +5469,6 @@ static void ice_remove(struct pci_dev *pdev) ice_set_wake(pf); ice_adapter_put(pdev); - pci_disable_device(pdev); } /** From patchwork Mon Sep 9 20:38:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13797572 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 3E5E218B464 for ; Mon, 9 Sep 2024 20:39:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914351; cv=none; b=CIqeS3QgGWHrtGI1GsdInd+uhQqE41F1j2rp8hF1NiPMSO7PsDbRdpeN6QQ3VB/ddv7Zh1oz9Rlatf/9ja+J277PyXhB8PC2Vm525mUPsr3IrbNU+ZsTUNNx6pBSuJyT4/+JCHwxf0VRsb23cwlymwg1wHpGjWWMQp5HGSf5yA4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914351; c=relaxed/simple; bh=2x928nSXQXV7uj/gf/2to7Leksq1hlurQB5fQK9gzec=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jZRo9L47L5WALz+g1Q034hy9N1Q+AopvFdpghyj3IljhkAuHP+GLzQYWbhzjoop0QnVIVwArbHajFCWh7ncrAXuHe4px34bD4NxT8uEtjrLJkB3XaiulxJ9dKXjKSeUgqLkdlUL3z5N2fP5ZpzJ+x0cv5wLgsr+GE/x837cQgKg= 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=KUQXLPWZ; arc=none smtp.client-ip=198.175.65.17 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="KUQXLPWZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725914349; x=1757450349; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=2x928nSXQXV7uj/gf/2to7Leksq1hlurQB5fQK9gzec=; b=KUQXLPWZCxy2xTlf99CsDW6MOG1oFChysCN3Ix3YdfIc/bGD6ie6AkQu UDLl6IqN6KQgcnhsLjB3Xz3lyS7CoOV2O6Wy1hMsyGIsROL2u42a9OmCr 5RuXh3/KbDF0DywM+BzcoTcBiKyrHy0wfuN/5Yf1xPtgb9axQ4caM4Qnj ikQooXDOIHolkOdGsfTFxknjHc21s3TSo/Dyp/ESONaHGW5nbNStV/MAN 6ZefkzOSuAFWPutkZFhDQR6nfn2hX6lB5ze23r/GHAaQAy1aiK0qrCyXC UI1hph7hl5azUeOxRz8oeyLKTqUnkk8UO5Wf/QE8ATPc+Iq4If4J/zdK7 Q==; X-CSE-ConnectionGUID: ZkOKEFjNQt6Eul3L8UikmA== X-CSE-MsgGUID: TiLBMvZ8QFagD7xmAkhpug== X-IronPort-AV: E=McAfee;i="6700,10204,11190"; a="24787138" X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="24787138" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 13:39:01 -0700 X-CSE-ConnectionGUID: X8bxScrZQvqm+coH4liDPw== X-CSE-MsgGUID: Pl85G7R2SFq6Lk7wzKU96A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="67054822" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa010.fm.intel.com with ESMTP; 09 Sep 2024 13:38:51 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Michal Schmidt , anthony.l.nguyen@intel.com, daniel.machon@microchip.com, Michal Swiatkowski , Dave Ertman , Rafal Romanowski Subject: [PATCH net 4/5] ice: fix VSI lists confusion when adding VLANs Date: Mon, 9 Sep 2024 13:38:40 -0700 Message-ID: <20240909203842.3109822-5-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240909203842.3109822-1-anthony.l.nguyen@intel.com> References: <20240909203842.3109822-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 Schmidt The description of function ice_find_vsi_list_entry says: Search VSI list map with VSI count 1 However, since the blamed commit (see Fixes below), the function no longer checks vsi_count. This causes a problem in ice_add_vlan_internal, where the decision to share VSI lists between filter rules relies on the vsi_count of the found existing VSI list being 1. The reproducing steps: 1. Have a PF and two VFs. There will be a filter rule for VLAN 0, referring to a VSI list containing VSIs: 0 (PF), 2 (VF#0), 3 (VF#1). 2. Add VLAN 1234 to VF#0. ice will make the wrong decision to share the VSI list with the new rule. The wrong behavior may not be immediately apparent, but it can be observed with debug prints. 3. Add VLAN 1234 to VF#1. ice will unshare the VSI list for the VLAN 1234 rule. Due to the earlier bad decision, the newly created VSI list will contain VSIs 0 (PF) and 3 (VF#1), instead of expected 2 (VF#0) and 3 (VF#1). 4. Try pinging a network peer over the VLAN interface on VF#0. This fails. Reproducer script at: https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/test-vlan-vsi-list-confusion.sh Commented debug trace: https://gitlab.com/mschmidt2/repro/-/blob/master/RHEL-46814/ice-vlan-vsi-lists-debug.txt Patch adding the debug prints: https://gitlab.com/mschmidt2/linux/-/commit/f8a8814623944a45091a77c6094c40bfe726bfdb (Unsafe, by the way. Lacks rule_lock when dumping in ice_remove_vlan.) Michal Swiatkowski added to the explanation that the bug is caused by reusing a VSI list created for VLAN 0. All created VFs' VSIs are added to VLAN 0 filter. When a non-zero VLAN is created on a VF which is already in VLAN 0 (normal case), the VSI list from VLAN 0 is reused. It leads to a problem because all VFs (VSIs to be specific) that are subscribed to VLAN 0 will now receive a new VLAN tag traffic. This is one bug, another is the bug described above. Removing filters from one VF will remove VLAN filter from the previous VF. It happens a VF is reset. Example: - creation of 3 VFs - we have VSI list (used for VLAN 0) [0 (pf), 2 (vf1), 3 (vf2), 4 (vf3)] - we are adding VLAN 100 on VF1, we are reusing the previous list because 2 is there - VLAN traffic works fine, but VLAN 100 tagged traffic can be received on all VSIs from the list (for example broadcast or unicast) - trust is turning on VF2, VF2 is resetting, all filters from VF2 are removed; the VLAN 100 filter is also removed because 3 is on the list - VLAN traffic to VF1 isn't working anymore, there is a need to recreate VLAN interface to readd VLAN filter One thing I'm not certain about is the implications for the LAG feature, which is another caller of ice_find_vsi_list_entry. I don't have a LAG-capable card at hand to test. Fixes: 23ccae5ce15f ("ice: changes to the interface with the HW and FW for SRIOV_VF+LAG") Reviewed-by: Michal Swiatkowski Signed-off-by: Michal Schmidt Reviewed-by: Dave Ertman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_switch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index 0160f0bae8d6..79d91e95358c 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -3264,7 +3264,7 @@ ice_find_vsi_list_entry(struct ice_hw *hw, u8 recp_id, u16 vsi_handle, list_head = &sw->recp_list[recp_id].filt_rules; list_for_each_entry(list_itr, list_head, list_entry) { - if (list_itr->vsi_list_info) { + if (list_itr->vsi_count == 1 && list_itr->vsi_list_info) { map_info = list_itr->vsi_list_info; if (test_bit(vsi_handle, map_info->vsi_map)) { *vsi_list_id = map_info->vsi_list_id; From patchwork Mon Sep 9 20:38:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13797566 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 8683318B493; Mon, 9 Sep 2024 20:39:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914349; cv=none; b=cEtZYMi3WNXKYfZApqnc+Djlxtsm4uPXXnYSosg/HZ7ihlHV7OD6tFM6Adqaw5FqmClIBbE2cKHRnLS6JX6QyClsd3caI6aLr/V1sqVMHJauUvbcmZNNqNWvHm3kC+Q11Kd2mKL5GgzmtNNNOdTSJT5LCfeH/7TSyjdXs7T+UnY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725914349; c=relaxed/simple; bh=+J2ZDO7XXPFMPQ8okrUFarcI2IZ4bQuVJchMzMjP6Cw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ka9zk6D+cKJcov+xnD9zz7zkPunpHlmi8AmbDyiBB082qKm7tk9hDfrgiAVrVnQZ/cGnFWI8Tg5uaE8aCLc1h/KZbVvlJ4Z637kEm0nivA3SyyV2JLbqCsJXs+ZgW+ecmESUbiZ25S6n+FZBLYmWgfZK9HaW1epq9hzNdYokhNc= 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=ki7jgxZU; arc=none smtp.client-ip=198.175.65.17 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="ki7jgxZU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725914348; x=1757450348; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+J2ZDO7XXPFMPQ8okrUFarcI2IZ4bQuVJchMzMjP6Cw=; b=ki7jgxZUQFrnlhY/szwASC7Gq6KgGWNAs3qgxvycHRPB/pjJx0DMm/cv YAMiuutxppD/0oimDwlJjAQoqPpZXp8eGJtUSjOnbpytsdVRbddLfQtfJ TPz+42iEDmrOQnhIn3J10m8s3FQWPSP5xOhdYIo/jtll4ytqFvTtZuU+q e6IOrPx17PoJTBkz4/AcUlt3l3GHm+jg723m3WR7/blsiMZ+Fa6NK3OEF 0wbRCvmk8Eyz6tje4P5myCeiWaCBSquhIjddr/5veycXIELL3oJYD48Z3 w3NZrxEi4krFi54FOiU7TGGcaB9wm838ebhg1M1iJBH+RxTleZjInF94T w==; X-CSE-ConnectionGUID: S8OMR9KNS+Ko4VGpxwCU3g== X-CSE-MsgGUID: E8lK/RBlSp2kwwXKuxYaUA== X-IronPort-AV: E=McAfee;i="6700,10204,11190"; a="24787125" X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="24787125" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 13:39:01 -0700 X-CSE-ConnectionGUID: E8ESHPY+T2GmMuSiR2rO8w== X-CSE-MsgGUID: ZWSZ7nDJSIeLAGX8dAxg7g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,215,1719903600"; d="scan'208";a="67054826" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa010.fm.intel.com with ESMTP; 09 Sep 2024 13:38:51 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Sriram Yagnaraman , anthony.l.nguyen@intel.com, sven.auhagen@voleatech.de, maciej.fijalkowski@intel.com, magnus.karlsson@intel.com, ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org, john.fastabend@gmail.com, bpf@vger.kernel.org, Kurt Kanzenbach , George Kuruvinakunnel Subject: [PATCH net 5/5] igb: Always call igb_xdp_ring_update_tail() under Tx lock Date: Mon, 9 Sep 2024 13:38:41 -0700 Message-ID: <20240909203842.3109822-6-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240909203842.3109822-1-anthony.l.nguyen@intel.com> References: <20240909203842.3109822-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Sriram Yagnaraman Always call igb_xdp_ring_update_tail() under __netif_tx_lock, add a comment and lockdep assert to indicate that. This is needed to share the same TX ring between XDP, XSK and slow paths. Furthermore, the current XDP implementation is racy on tail updates. Fixes: 9cbc948b5a20 ("igb: add XDP support") Signed-off-by: Sriram Yagnaraman [Kurt: Add lockdep assert and fixes tag] Signed-off-by: Kurt Kanzenbach Acked-by: Maciej Fijalkowski Tested-by: George Kuruvinakunnel Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/igb/igb_main.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c index 9dc7c60838ed..1ef4cb871452 100644 --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -33,6 +33,7 @@ #include #include #include +#include #ifdef CONFIG_IGB_DCA #include #endif @@ -2914,8 +2915,11 @@ static int igb_xdp(struct net_device *dev, struct netdev_bpf *xdp) } } +/* This function assumes __netif_tx_lock is held by the caller. */ static void igb_xdp_ring_update_tail(struct igb_ring *ring) { + lockdep_assert_held(&txring_txq(ring)->_xmit_lock); + /* Force memory writes to complete before letting h/w know there * are new descriptors to fetch. */ @@ -3000,11 +3004,11 @@ static int igb_xdp_xmit(struct net_device *dev, int n, nxmit++; } - __netif_tx_unlock(nq); - if (unlikely(flags & XDP_XMIT_FLUSH)) igb_xdp_ring_update_tail(tx_ring); + __netif_tx_unlock(nq); + return nxmit; } @@ -8864,12 +8868,14 @@ static void igb_put_rx_buffer(struct igb_ring *rx_ring, static int igb_clean_rx_irq(struct igb_q_vector *q_vector, const int budget) { + unsigned int total_bytes = 0, total_packets = 0; struct igb_adapter *adapter = q_vector->adapter; struct igb_ring *rx_ring = q_vector->rx.ring; - struct sk_buff *skb = rx_ring->skb; - unsigned int total_bytes = 0, total_packets = 0; u16 cleaned_count = igb_desc_unused(rx_ring); + struct sk_buff *skb = rx_ring->skb; + int cpu = smp_processor_id(); unsigned int xdp_xmit = 0; + struct netdev_queue *nq; struct xdp_buff xdp; u32 frame_sz = 0; int rx_buf_pgcnt; @@ -8997,7 +9003,10 @@ static int igb_clean_rx_irq(struct igb_q_vector *q_vector, const int budget) if (xdp_xmit & IGB_XDP_TX) { struct igb_ring *tx_ring = igb_xdp_tx_queue_mapping(adapter); + nq = txring_txq(tx_ring); + __netif_tx_lock(nq, cpu); igb_xdp_ring_update_tail(tx_ring); + __netif_tx_unlock(nq); } u64_stats_update_begin(&rx_ring->rx_syncp);