From patchwork Wed Mar 5 21:35:43 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 14003453 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 5BAD925743D for ; Wed, 5 Mar 2025 21:36:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210564; cv=none; b=RVUNtzU4YP0XQW18fCqztlB6QizBL4cvYsV7y7efsAaJOG0So+qZvVslmymb7AEom1+STo0Ee+7IOgbfQjaSf63ubLNg+9epWJKXVsDYY3j047NHO8k3ZhN8K22GnLRem3kTBYV0kCr+OhP0L2I8rGJ3aKdfR3g9xh8sOwTfR+k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210564; c=relaxed/simple; bh=GuwR3mhZuYCpbs97AgybkQQLFzvRbxU8C1+NMIk78bE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qspp+z/Qy9kZSJPKRC6biVIn0Xw8Er2cc0A5tx91ilHCWGHkiTn12aCuTANk2NOMNJC/PA0KHCv4oOc6P7uU98XpAb3Clky/aSn1XK/plMVun3+wM+njykJnTplu5uAvHPgzus/WkkBK4JSghAL9z8q9thIJEQfcnXvgD4h5B2c= 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=azQMfHjX; arc=none smtp.client-ip=192.198.163.10 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="azQMfHjX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741210562; x=1772746562; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GuwR3mhZuYCpbs97AgybkQQLFzvRbxU8C1+NMIk78bE=; b=azQMfHjXyWVuxJXh7IxWs+o8v4xevsiFyEqbSxG4lmmDxfsVKJu//btd q8GQfmJku1wTvKNPk5gBHtxz7mHy3MYEbG6C/O1RRY+dPB3Gdc4qj0DSF SO88jvL1gZw/J8zFm6GWFtvlZNJaLZMaAL8La0QRNZrfrIim31qMi4STa J1LlXX2ScVgGWvKFaZBJaI6DtThQp4qAdMSj7w0IQdJGM5b7wfa1vLh8L zjdgVGWQiL984n8amoMvWh1uAuVfRjIO/9ldAq8rSBvS7MWnG2ZRKCpUE Uurn3BAdGGC0iZV3LNlfsPN8qrmsrbvFxF9sFiwAYLwBIUEKIGMTpifu/ Q==; X-CSE-ConnectionGUID: gnLZwB+YRimqdJK4CUTPjQ== X-CSE-MsgGUID: Pf1LNsq/QOCnpMfgupGBAg== X-IronPort-AV: E=McAfee;i="6700,10204,11363"; a="53606486" X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="53606486" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2025 13:35:58 -0800 X-CSE-ConnectionGUID: npqG6Qf4Q7Szb3WKbwhW8A== X-CSE-MsgGUID: yBTuF3EUThCSE/rMIeI8GQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="123828479" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa004.jf.intel.com with ESMTP; 05 Mar 2025 13:35:55 -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: Larysa Zaremba , anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, przemyslaw.kitszel@intel.com, Simon Horman , Sujai Buvaneswaran Subject: [PATCH net 1/4] ice: do not configure destination override for switchdev Date: Wed, 5 Mar 2025 13:35:43 -0800 Message-ID: <20250305213549.1514274-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250305213549.1514274-1-anthony.l.nguyen@intel.com> References: <20250305213549.1514274-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: Larysa Zaremba After switchdev is enabled and disabled later, LLDP packets sending stops, despite working perfectly fine before and during switchdev state. To reproduce (creating/destroying VF is what triggers the reconfiguration): devlink dev eswitch set pci/
mode switchdev echo '2' > /sys/class/net//device/sriov_numvfs echo '0' > /sys/class/net//device/sriov_numvfs This happens because LLDP relies on the destination override functionality. It needs to 1) set a flag in the descriptor, 2) set the VSI permission to make it valid. The permissions are set when the PF VSI is first configured, but switchdev then enables it for the uplink VSI (which is always the PF) once more when configured and disables when deconfigured, which leads to software-generated LLDP packets being blocked. Do not modify the destination override permissions when configuring switchdev, as the enabled state is the default configuration that is never modified. Fixes: 1a1c40df2e80 ("ice: set and release switchdev environment") Reviewed-by: Michal Swiatkowski Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_eswitch.c | 6 ------ drivers/net/ethernet/intel/ice/ice_lib.c | 18 ------------------ drivers/net/ethernet/intel/ice/ice_lib.h | 4 ---- 3 files changed, 28 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c b/drivers/net/ethernet/intel/ice/ice_eswitch.c index d649c197cf67..ed21d7f55ac1 100644 --- a/drivers/net/ethernet/intel/ice/ice_eswitch.c +++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c @@ -49,9 +49,6 @@ static int ice_eswitch_setup_env(struct ice_pf *pf) if (vlan_ops->dis_rx_filtering(uplink_vsi)) goto err_vlan_filtering; - if (ice_vsi_update_security(uplink_vsi, ice_vsi_ctx_set_allow_override)) - goto err_override_uplink; - if (ice_vsi_update_local_lb(uplink_vsi, true)) goto err_override_local_lb; @@ -63,8 +60,6 @@ static int ice_eswitch_setup_env(struct ice_pf *pf) err_up: ice_vsi_update_local_lb(uplink_vsi, false); err_override_local_lb: - ice_vsi_update_security(uplink_vsi, ice_vsi_ctx_clear_allow_override); -err_override_uplink: vlan_ops->ena_rx_filtering(uplink_vsi); err_vlan_filtering: ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx, false, @@ -275,7 +270,6 @@ static void ice_eswitch_release_env(struct ice_pf *pf) vlan_ops = ice_get_compat_vsi_vlan_ops(uplink_vsi); ice_vsi_update_local_lb(uplink_vsi, false); - ice_vsi_update_security(uplink_vsi, ice_vsi_ctx_clear_allow_override); vlan_ops->ena_rx_filtering(uplink_vsi); ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx, false, ICE_FLTR_TX); diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c index 38a1c8372180..d0faa087793d 100644 --- a/drivers/net/ethernet/intel/ice/ice_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_lib.c @@ -3936,24 +3936,6 @@ void ice_vsi_ctx_clear_antispoof(struct ice_vsi_ctx *ctx) ICE_AQ_VSI_SEC_TX_PRUNE_ENA_S); } -/** - * ice_vsi_ctx_set_allow_override - allow destination override on VSI - * @ctx: pointer to VSI ctx structure - */ -void ice_vsi_ctx_set_allow_override(struct ice_vsi_ctx *ctx) -{ - ctx->info.sec_flags |= ICE_AQ_VSI_SEC_FLAG_ALLOW_DEST_OVRD; -} - -/** - * ice_vsi_ctx_clear_allow_override - turn off destination override on VSI - * @ctx: pointer to VSI ctx structure - */ -void ice_vsi_ctx_clear_allow_override(struct ice_vsi_ctx *ctx) -{ - ctx->info.sec_flags &= ~ICE_AQ_VSI_SEC_FLAG_ALLOW_DEST_OVRD; -} - /** * ice_vsi_update_local_lb - update sw block in VSI with local loopback bit * @vsi: pointer to VSI structure diff --git a/drivers/net/ethernet/intel/ice/ice_lib.h b/drivers/net/ethernet/intel/ice/ice_lib.h index eabb35834a24..b4c9cb28a016 100644 --- a/drivers/net/ethernet/intel/ice/ice_lib.h +++ b/drivers/net/ethernet/intel/ice/ice_lib.h @@ -105,10 +105,6 @@ ice_vsi_update_security(struct ice_vsi *vsi, void (*fill)(struct ice_vsi_ctx *)) void ice_vsi_ctx_set_antispoof(struct ice_vsi_ctx *ctx); void ice_vsi_ctx_clear_antispoof(struct ice_vsi_ctx *ctx); - -void ice_vsi_ctx_set_allow_override(struct ice_vsi_ctx *ctx); - -void ice_vsi_ctx_clear_allow_override(struct ice_vsi_ctx *ctx); int ice_vsi_update_local_lb(struct ice_vsi *vsi, bool set); int ice_vsi_add_vlan_zero(struct ice_vsi *vsi); int ice_vsi_del_vlan_zero(struct ice_vsi *vsi); From patchwork Wed Mar 5 21:35:44 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 14003455 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 35A5F25BAD7 for ; Wed, 5 Mar 2025 21:36:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210565; cv=none; b=KfWS/8NC/+Yd1uD8Q0yIxy4Y2GDNlb6j6i3J5r5vUTxaseQWdZB0riNSl0HLwPRxt2MM/kUr80Hit51yL1cuFk2jAROdgf4PyWkoQd7Nl8I2VUBS5Y2zLzuNzKBiBW8zmKED5yCGTcCRhN6wqx7eZhH5l4Y7NCr/llYH9PLPLB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210565; c=relaxed/simple; bh=uNRKKVqID7kZB9OgAHMn4nS931Qj79b5NBPgV2Wo9fY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iqr30iwudkegsveUbFXLl+Q/fNSOZ36JG5sbDKYoF/7bRn9SYNjwVXIbC+0Wt4XojJgILE6HGZdkalpGT7E1zXjKyOl/Vu46HELajS1wOoG1+yRWTdXWrXgNIiWydUhXB8ODW48mswPtfk010pt+K81f6VBZ6J7amfSA+QluFhg= 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=SBD2S2yd; arc=none smtp.client-ip=192.198.163.10 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="SBD2S2yd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741210564; x=1772746564; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=uNRKKVqID7kZB9OgAHMn4nS931Qj79b5NBPgV2Wo9fY=; b=SBD2S2ydO1SiCN8r2ilvgKkyHYMDKUAUqlE3gXoPegaO+jgeK3fCUI9j ClQ5fOPBADtr+i7tucoNJvuQpYg8yc6yd/bBxbQrPOU5Z/ukd+qEZiVC9 ncAxU4bIOvaX+0TBFdPnbyXydJG34uvVT40FXydqC/D69mEROeMQanSvV U+9Te6gdO9AygBA/sHjdGm4H+t5GN/21De9V1kcFZ/Iu2Ytf4z5Qn2b5k 7eSU0uuaVNYvTltLi14JBZu8aaExU3XJGu4ZIJoUg+Vt8ZpcLk9oOyXu3 u+Fsw6bRuwjlovdsYaqsd7l1KWZ4tNvR3HnN89I8xyaSEc7HoSceg4M0O Q==; X-CSE-ConnectionGUID: lAFSCCvqR8KgK0D4/WmWQA== X-CSE-MsgGUID: aR3dfUkbQ0io9UcQPAAcdw== X-IronPort-AV: E=McAfee;i="6700,10204,11363"; a="53606497" X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="53606497" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2025 13:35:58 -0800 X-CSE-ConnectionGUID: Ga2Be8GyRtm+JnoU0n3NSQ== X-CSE-MsgGUID: 1+NjlbOpRnW7fmldOVb1iw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="123828483" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa004.jf.intel.com with ESMTP; 05 Mar 2025 13:35:55 -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: Grzegorz Nitka , anthony.l.nguyen@intel.com, Michal Swiatkowski , Simon Horman , Rinitha S Subject: [PATCH net 2/4] ice: fix memory leak in aRFS after reset Date: Wed, 5 Mar 2025 13:35:44 -0800 Message-ID: <20250305213549.1514274-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250305213549.1514274-1-anthony.l.nguyen@intel.com> References: <20250305213549.1514274-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: Grzegorz Nitka Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [] __kmalloc_cache_noprof+0x275/0x340 [] ice_init_arfs+0x3a/0xe0 [ice] [] ice_vsi_cfg_def+0x607/0x850 [ice] [] ice_vsi_setup+0x5b/0x130 [ice] [] ice_init+0x1c1/0x460 [ice] [] ice_probe+0x2af/0x520 [ice] [] local_pci_probe+0x43/0xa0 [] work_for_cpu_fn+0x13/0x20 [] process_one_work+0x179/0x390 [] worker_thread+0x239/0x340 [] kthread+0xcc/0x100 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30 ... Fixes: 28bf26724fdb ("ice: Implement aRFS") Reviewed-by: Michal Swiatkowski Signed-off-by: Grzegorz Nitka Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_arfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_arfs.c b/drivers/net/ethernet/intel/ice/ice_arfs.c index 7cee365cc7d1..405ddd17de1b 100644 --- a/drivers/net/ethernet/intel/ice/ice_arfs.c +++ b/drivers/net/ethernet/intel/ice/ice_arfs.c @@ -511,7 +511,7 @@ void ice_init_arfs(struct ice_vsi *vsi) struct hlist_head *arfs_fltr_list; unsigned int i; - if (!vsi || vsi->type != ICE_VSI_PF) + if (!vsi || vsi->type != ICE_VSI_PF || ice_is_arfs_active(vsi)) return; arfs_fltr_list = kcalloc(ICE_MAX_ARFS_LIST, sizeof(*arfs_fltr_list), From patchwork Wed Mar 5 21:35:45 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 14003452 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 BA91425BADB for ; Wed, 5 Mar 2025 21:36:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210563; cv=none; b=nOnqP8g+6E2x663mla2KTsOwccEeuu71iW0aTsTlCPW38jF/c3uTFvIn+/7sBNA/uUXzsBwvNkhEMzBq1XamxFTWm6blLK3Ud6xn5f7vc3URbNr//6URgkYuCReC0A1EDVL+kPEAROwQU7wc/sr/hyT60pXCAYLAQlN2d75wWy4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210563; c=relaxed/simple; bh=/sCB1Dq1vBtS9I7Os9cb7agZpe7e8iUsSJxkfOPBqw4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oaMH7h7UDHM2vS1CkFc1iSFCs8i9HEEHuVI2OFcBVfbr9wsg0x+/KMMmwpZ0Ng8AFsNYczdpPKTr53Smicj2oGib1gEpwyXwqWQUTcWKkWsEHQgMs1DVT4OkosNBmTFOLMcRTDeLLPDSFvydOvE02/kpvPCBKL4vCjJ5K6F97IY= 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=RmmSbK2V; arc=none smtp.client-ip=192.198.163.10 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="RmmSbK2V" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741210561; x=1772746561; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/sCB1Dq1vBtS9I7Os9cb7agZpe7e8iUsSJxkfOPBqw4=; b=RmmSbK2VDKE1Ir647dD2sRgoIctuVMeSA7X2kPP9MoMwVFxUP3+aAXqX 9XachCLnHmyR1m3DiSj49ys+csLQ+gqC+A+NYRxGjoQQLoyk6mYnUSZlz fMRvj2EhZ31wdkUnJmbr67E20ivGuNZXadRuqD40Wr5Ln7V2Ny3RM7QZ6 M+CBJI0jOgedpdaEZz6HswEtq4aqM2TGktWQ/dYa34JZezaN1EFGIafSC k2rQ9D2LchjMtt2kcOsmxRsksZWAvOQNjL4cbhiyOTAELbv1dDa4wzF6w hhBfGveMrE6VJvAXdN/3SAOU9bYNI8eVulen9vvr/LOxEY2b1FvCgzFXT w==; X-CSE-ConnectionGUID: RKtaG4WZQamZ1JXRmJHqSQ== X-CSE-MsgGUID: Xa5H10x9QIKeR9vfHzureQ== X-IronPort-AV: E=McAfee;i="6700,10204,11363"; a="53606479" X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="53606479" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2025 13:35:57 -0800 X-CSE-ConnectionGUID: z72tyXKnRCmo1L2HK0VTWg== X-CSE-MsgGUID: XxfTurKaQ2qx0I4bl8dxzw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="123828486" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa004.jf.intel.com with ESMTP; 05 Mar 2025 13:35:55 -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: Marcin Szycik , anthony.l.nguyen@intel.com, Michal Swiatkowski , Simon Horman , Rafal Romanowski , Sujai Buvaneswaran Subject: [PATCH net 3/4] ice: Fix switchdev slow-path in LAG Date: Wed, 5 Mar 2025 13:35:45 -0800 Message-ID: <20250305213549.1514274-4-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250305213549.1514274-1-anthony.l.nguyen@intel.com> References: <20250305213549.1514274-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: Marcin Szycik Ever since removing switchdev control VSI and using PF for port representor Tx/Rx, switchdev slow-path has been working improperly after failover in SR-IOV LAG. LAG assumes that the first uplink to be added to the aggregate will own VFs and have switchdev configured. After failing-over to the other uplink, representors are still configured to Tx through the uplink they are set up on, which fails because that uplink is now down. On failover, update all PRs on primary uplink to use the currently active uplink for Tx. Call netif_keep_dst(), as the secondary uplink might not be in switchdev mode. Also make sure to call ice_eswitch_set_target_vsi() if uplink is in LAG. On the Rx path, representors are already working properly, because default Tx from VFs is set to PF owning the eswitch. After failover the same PF is receiving traffic from VFs, even though link is down. Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path") Reviewed-by: Michal Swiatkowski Signed-off-by: Marcin Szycik Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_lag.c | 27 +++++++++++++++++++++++ drivers/net/ethernet/intel/ice/ice_txrx.c | 4 +++- 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c b/drivers/net/ethernet/intel/ice/ice_lag.c index 1ccb572ce285..22371011c249 100644 --- a/drivers/net/ethernet/intel/ice/ice_lag.c +++ b/drivers/net/ethernet/intel/ice/ice_lag.c @@ -1000,6 +1000,28 @@ static void ice_lag_link(struct ice_lag *lag) netdev_info(lag->netdev, "Shared SR-IOV resources in bond are active\n"); } +/** + * ice_lag_config_eswitch - configure eswitch to work with LAG + * @lag: lag info struct + * @netdev: active network interface device struct + * + * Updates all port representors in eswitch to use @netdev for Tx. + * + * Configures the netdev to keep dst metadata (also used in representor Tx). + * This is required for an uplink without switchdev mode configured. + */ +static void ice_lag_config_eswitch(struct ice_lag *lag, + struct net_device *netdev) +{ + struct ice_repr *repr; + unsigned long id; + + xa_for_each(&lag->pf->eswitch.reprs, id, repr) + repr->dst->u.port_info.lower_dev = netdev; + + netif_keep_dst(netdev); +} + /** * ice_lag_unlink - handle unlink event * @lag: LAG info struct @@ -1021,6 +1043,9 @@ static void ice_lag_unlink(struct ice_lag *lag) ice_lag_move_vf_nodes(lag, act_port, pri_port); lag->primary = false; lag->active_port = ICE_LAG_INVALID_PORT; + + /* Config primary's eswitch back to normal operation. */ + ice_lag_config_eswitch(lag, lag->netdev); } else { struct ice_lag *primary_lag; @@ -1419,6 +1444,7 @@ static void ice_lag_monitor_active(struct ice_lag *lag, void *ptr) ice_lag_move_vf_nodes(lag, prim_port, event_port); lag->active_port = event_port; + ice_lag_config_eswitch(lag, event_netdev); return; } @@ -1428,6 +1454,7 @@ static void ice_lag_monitor_active(struct ice_lag *lag, void *ptr) /* new active port */ ice_lag_move_vf_nodes(lag, lag->active_port, event_port); lag->active_port = event_port; + ice_lag_config_eswitch(lag, event_netdev); } else { /* port not set as currently active (e.g. new active port * has already claimed the nodes and filters diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c index 9c9ea4c1b93b..380ba1e8b3b2 100644 --- a/drivers/net/ethernet/intel/ice/ice_txrx.c +++ b/drivers/net/ethernet/intel/ice/ice_txrx.c @@ -2424,7 +2424,9 @@ ice_xmit_frame_ring(struct sk_buff *skb, struct ice_tx_ring *tx_ring) ICE_TXD_CTX_QW1_CMD_S); ice_tstamp(tx_ring, skb, first, &offload); - if (ice_is_switchdev_running(vsi->back) && vsi->type != ICE_VSI_SF) + if ((ice_is_switchdev_running(vsi->back) || + ice_lag_is_switchdev_running(vsi->back)) && + vsi->type != ICE_VSI_SF) ice_eswitch_set_target_vsi(skb, &offload); if (offload.cd_qw1 & ICE_TX_DESC_DTYPE_CTX) { From patchwork Wed Mar 5 21:35:46 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 14003454 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 A27F1257AC8 for ; Wed, 5 Mar 2025 21:36:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210565; cv=none; b=qGRr6dXXngBPA+WzqXsGhA9u65k4nQ+Ucv0qeGV0jMsJxMS9EE/YPdol1J8Z2+a8qQD6iols2n6Dw2TYlQ+xeA8fmndHq1aIqaa9WrKdz1qnXr66qBgnYg0V4RbUuQ+whc3ysNH/2VOaZ2iMf+iA8P6yePkptPx6CM8q7b+rWeQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741210565; c=relaxed/simple; bh=xZF9mGXmB44HOH7lioiVMEtFdGRrl8k8zjhnuToNjeY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eNS/FgsIxu7Zik7bZeQOKI/6OvCw2fL2KwALTicSRanIuxeTqCj0W4LiVXZKWUYrWmW7RN53PSVob4mrjPo0ORqSQ6XglET/jMEhgju7fQ1FHHCmk0hD55jyIADuVHMQnO4ZVp3aV8VpeZQTatKb+BLX5vKjmIIlHirvpWnVgAs= 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=gdKFtwFp; arc=none smtp.client-ip=192.198.163.10 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="gdKFtwFp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741210563; x=1772746563; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=xZF9mGXmB44HOH7lioiVMEtFdGRrl8k8zjhnuToNjeY=; b=gdKFtwFpqTGfowsAujvOUP749vlbWlrZRb3+aR45Mp5TsPkjg7itll52 5b6X0MVH77W++EfQbxDMhMm0qsKD7v1ngCioZNPO52G2w7SrqsSqwvIbJ fbVTAR/11NSaEYNfi7lWyQWx6lhD18oMUzDzJTG/cpsR1J8pifKmwScWr GwudlykpvjI6Ck/s20bqwYpuAVNwX2AsiVJ+7Is8fAhabuhVNqcGgLgUm HyQnvXWaJ1dX2buGJX2tz1iGC3UR/A/QtNzVdOhFpUFfVAEbJY8h3qwju twsXsRGelR0CUd6QkPPmmEAgjIQkLQXKHcTgrBwRHXDjTyViI82ZMGrXE A==; X-CSE-ConnectionGUID: YrktvPoCSd+fYFKrXcUXKg== X-CSE-MsgGUID: g0ekssfgQIWIE6HILmgBRA== X-IronPort-AV: E=McAfee;i="6700,10204,11363"; a="53606493" X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="53606493" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2025 13:35:58 -0800 X-CSE-ConnectionGUID: WqN3wkqxQJOoI/hqvNLBnA== X-CSE-MsgGUID: tXylPksPR9KNFoJRv06QRQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,224,1736841600"; d="scan'208";a="123828489" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa004.jf.intel.com with ESMTP; 05 Mar 2025 13:35:55 -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, jiri@resnulli.us, Aleksandr Loktionov , Michal Swiatkowski , Konrad Knitter , Sunitha Mekala Subject: [PATCH net 4/4] ice: register devlink prior to creating health reporters Date: Wed, 5 Mar 2025 13:35:46 -0800 Message-ID: <20250305213549.1514274-5-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250305213549.1514274-1-anthony.l.nguyen@intel.com> References: <20250305213549.1514274-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 ice_health_init() was introduced in the commit 2a82874a3b7b ("ice: add Tx hang devlink health reporter"). The call to it should have been put after ice_devlink_register(). It went unnoticed until next reporter by Konrad, which receives events from FW. FW is reporting all events, also from prior driver load, and thus it is not unlikely to have something at the very beginning. And that results in a splat: [ 24.455950] ? devlink_recover_notify.constprop.0+0x198/0x1b0 [ 24.455973] devlink_health_report+0x5d/0x2a0 [ 24.455976] ? __pfx_ice_health_status_lookup_compare+0x10/0x10 [ice] [ 24.456044] ice_process_health_status_event+0x1b7/0x200 [ice] Do the analogous thing for deinit patch. Fixes: 85d6164ec56d ("ice: add fw and port health reporters") Reviewed-by: Aleksandr Loktionov Reviewed-by: Michal Swiatkowski Reviewed-by: Konrad Knitter Signed-off-by: Przemek Kitszel Tested-by: Sunitha Mekala (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index c3a0fb97c5ee..e13bd5a6cb6c 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -5065,16 +5065,16 @@ static int ice_init_devlink(struct ice_pf *pf) return err; ice_devlink_init_regions(pf); - ice_health_init(pf); ice_devlink_register(pf); + ice_health_init(pf); return 0; } static void ice_deinit_devlink(struct ice_pf *pf) { - ice_devlink_unregister(pf); ice_health_deinit(pf); + ice_devlink_unregister(pf); ice_devlink_destroy_regions(pf); ice_devlink_unregister_params(pf); }