From patchwork Mon Sep 30 22:35:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817189 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 650CF188A1A for ; Mon, 30 Sep 2024 22:36:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735769; cv=none; b=D0X0dd2NSiSorUrkJy7+dqaKky1EX6GXVQahxYmhmbW0kWl82h5yhLVDeG0KuIDPoj2SWEzRuyxUmJ9cKwzH7ghNQbSmLkZR14CRzltMaP7P6nsXrtCaMOLvFZnUcMmU0lA+x1CyAkqir/Q2SabJFtH0Cml2cJSGHas/rnvN7oo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735769; c=relaxed/simple; bh=PS9nIrBKXKXl2LyWoaHKQPTE1UYeJftI22u4tb9Q4/Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YqbOTnuXgX15N/Z+L0r4aiQ0OpDGNj0w6+4IrrVjuCjwnrX5HQHUj0478/eqFaomjnkz3rbyJYKoSlvEQTfiuC6H6c++Quf6CHO9jVu6ECs3K0UzEUtMhP/5e87wo2k1AH5vNf+d06IHxqJA6odVWGs3IhF7PNUas7KmcGaGEZk= 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=ntdX97rc; arc=none smtp.client-ip=192.198.163.12 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="ntdX97rc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735767; x=1759271767; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=PS9nIrBKXKXl2LyWoaHKQPTE1UYeJftI22u4tb9Q4/Q=; b=ntdX97rcTelAdTNLH6uyoDzdFyMeF9G+6tgnNZtss7Nnda+kw9yH97VM V9M2DrQyBaSM0LV5rBX2pF76sYKfO0F1MYz41uHBPFtvHxTOaQ2lrJ8hI +31AjhwIUWmoVqWp9mhOKXVZfd5yrhBS7JW+stxU18ORoANAjq6YX7XAs +daWeB+OFcJZgyxVv6r9yT1Gj1x8X/QoOHQmNauisJE5fuQpA7x8fwNPc c+hGO/Z/z4CugtV7p+GTuuh9+cH+jHlS9hOpG5uYtIhiM1GLy/5ePkXHe 8/UswKt47UpTjX0zCskqeEh6xQmFkVkePnBW+nEDUh4sJtZFN+vtawm7s A==; X-CSE-ConnectionGUID: uikE3ZsISACHZzaudOyZ0A== X-CSE-MsgGUID: G6iBHLu3QpuprSWos5Gy5w== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734850" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734850" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:05 -0700 X-CSE-ConnectionGUID: rrrDuzTARPebGhB/MV64Ow== X-CSE-MsgGUID: 5W3Z5cUPTN6v7aXh9LJuWw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496607" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:06 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Michal Swiatkowski , anthony.l.nguyen@intel.com, wojciech.drewek@intel.com, pmenzel@molgen.mpg.de, Przemek Kitszel , Jacob Keller , Sujai Buvaneswaran Subject: [PATCH net 01/10] ice: set correct dst VSI in only LAN filters Date: Mon, 30 Sep 2024 15:35:48 -0700 Message-ID: <20240930223601.3137464-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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 The filters set that will reproduce the problem: $ tc filter add dev $VF0_PR ingress protocol arp prio 0 flower \ skip_sw dst_mac ff:ff:ff:ff:ff:ff action mirred egress \ redirect dev $PF0 $ tc filter add dev $VF0_PR ingress protocol arp prio 0 flower \ skip_sw dst_mac ff:ff:ff:ff:ff:ff src_mac 52:54:00:00:00:10 \ action mirred egress mirror dev $VF1_PR Expected behaviour is to set all broadcast from VF0 to the LAN. If the src_mac match the value from filters, send packet to LAN and to VF1. In this case both LAN_EN and LB_EN flags in switch is set in case of packet matching both filters. As dst VSI for the only LAN enable bit is PF VSI, the packet is being seen on PF. To fix this change dst VSI to the source VSI. It will block receiving any packet even when LB_EN is set by switch, because local loopback is clear on VF VSI during normal operation. Side note: if the second filters action is redirect instead of mirror LAN_EN is clear, because switch is AND-ing LAN_EN from each matched filters and OR-ing LB_EN. Reviewed-by: Przemek Kitszel Fixes: 73b483b79029 ("ice: Manage act flags for switchdev offloads") Signed-off-by: Michal Swiatkowski Reviewed-by: Jacob Keller Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_tc_lib.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c index e6923f8121a9..ea39b999a0d0 100644 --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c @@ -819,6 +819,17 @@ ice_eswitch_add_tc_fltr(struct ice_vsi *vsi, struct ice_tc_flower_fltr *fltr) rule_info.sw_act.flag |= ICE_FLTR_TX; rule_info.sw_act.src = vsi->idx; rule_info.flags_info.act = ICE_SINGLE_ACT_LAN_ENABLE; + /* This is a specific case. The destination VSI index is + * overwritten by the source VSI index. This type of filter + * should allow the packet to go to the LAN, not to the + * VSI passed here. It should set LAN_EN bit only. However, + * the VSI must be a valid one. Setting source VSI index + * here is safe. Even if the result from switch is set LAN_EN + * and LB_EN (which normally will pass the packet to this VSI) + * packet won't be seen on the VSI, because local loopback is + * turned off. + */ + rule_info.sw_act.vsi_handle = vsi->idx; } else { /* VF to VF */ rule_info.sw_act.flag |= ICE_FLTR_TX; From patchwork Mon Sep 30 22:35:49 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817190 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 02CDD188CDC; Mon, 30 Sep 2024 22:36:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735769; cv=none; b=uB1Phm62PMRWX2386X2A5qoEmlZn6SSF8PRAf882mToEeGhgXNaMdcHltWM5icRWPcqYB1u4rHtrjRN1iOZoBAemO7HTPNMCRZAgWc500ehZz4seDeYp0w9yb7oudSE9TkAuIYTxLaJQ05BH536f7LsrspmHmoACJrHQRsP3j3k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735769; c=relaxed/simple; bh=PKn7oc2AZRvdVDnrmUspmIG/9ddRENlq1gIXvjjGLdI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hl4Yyj6f1k3A254VZhLommjHmWDYfnGlsohh5GUg2DMRfDsDQusnhiZ1aWkb/pVxqZuot1k+mVt4y0MLV9T0vY0zhwTgJVdIL0bfqCI8zV8ixX6tsIenj6mQUP6Is5reUeqyWXmUeG/d/M3TWXjHNyFbOyq4rU1LYlx7TbFE5bI= 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=JbhK0Mw6; arc=none smtp.client-ip=192.198.163.12 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="JbhK0Mw6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735768; x=1759271768; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=PKn7oc2AZRvdVDnrmUspmIG/9ddRENlq1gIXvjjGLdI=; b=JbhK0Mw6DkoDsWv3F8Y8g72XB6jShL+cFroEzPSkeYUXpQYAJFC+k0uz qnpviS5ImU/WlpduP65xNN++Txa0AiHBP4j8/FeBNgp/6xyTmwcaIzuEV AUdWKkqOXURcWHiULEnj5Wub9SYMlOtQgQlEIE2+8mwtjAlGXNPoJ+6y4 aJTKleE9TgIlNyyWYraujgb9f2wogieq9jfvihB/ZNeJmHC8MioGW1jF1 tIR7Nine4jbAQvT2QQSpPW3D9+ufdOsl/WreywSfN3asBexHoz1g3Ko/d BEm8zr4HbVsw9eXhGO2njHjhZ3XkmKNBIORuqO1A17rvcEf9qa1tGRid7 A==; X-CSE-ConnectionGUID: 8BjGIhunRumTpHGQ0uw6Ew== X-CSE-MsgGUID: 2CVOrnilRminBHjE1br+gg== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734856" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734856" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: NmXZQtPNS/m2yuX930RRGw== X-CSE-MsgGUID: 983sn0jNQhKNDcZVlwVEwg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496611" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:06 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Gui-Dong Han , anthony.l.nguyen@intel.com, baijiaju1990@gmail.com, arkadiusz.kubalewski@intel.com, vadim.fedorenko@linux.dev, jiri@resnulli.us, stable@vger.kernel.org, Simon Horman , Pucha Himasekhar Reddy Subject: [PATCH net 02/10] ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() Date: Mon, 30 Sep 2024 15:35:49 -0700 Message-ID: <20240930223601.3137464-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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: Gui-Dong Han This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Reviewed-by: Simon Horman Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Reviewed-by: Vadim Fedorenko --- drivers/net/ethernet/intel/ice/ice_dpll.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c index cd95705d1e7f..8b6dc4d54fdc 100644 --- a/drivers/net/ethernet/intel/ice/ice_dpll.c +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c @@ -1843,6 +1843,8 @@ ice_dpll_init_rclk_pins(struct ice_pf *pf, struct ice_dpll_pin *pin, struct dpll_pin *parent; int ret, i; + if (WARN_ON((!vsi || !vsi->netdev))) + return -EINVAL; ret = ice_dpll_get_pins(pf, pin, start_idx, ICE_DPLL_RCLK_NUM_PER_PF, pf->dplls.clock_id); if (ret) @@ -1858,8 +1860,6 @@ ice_dpll_init_rclk_pins(struct ice_pf *pf, struct ice_dpll_pin *pin, if (ret) goto unregister_pins; } - if (WARN_ON((!vsi || !vsi->netdev))) - return -EINVAL; dpll_netdev_pin_set(vsi->netdev, pf->dplls.rclk.pin); return 0; From patchwork Mon Sep 30 22:35:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817191 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 AE86218951C; Mon, 30 Sep 2024 22:36:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735770; cv=none; b=F7IEGgiU50mxEZ9S8EvVx4GOp+VUnLJnFNb5FV/QFqDBH+XN2YXIarwE+3T/meoZHZE1WzrM7CZAmzdDcPhIEkUEoRv20q/rxTWCxZ+cj1kfmMfoK0vZUVoZ46uI1PlgCiGik+aneQIJtfRNSqrKobrZH0Bv/HhZoL7+ewufkj8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735770; c=relaxed/simple; bh=BqBjza3dVs7RuLhK/O/xvl0SxSraob6n8ODHpbQfFmE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h64sg2jAXvEJsy8CdlOddk3wRfSHSz0wpIvgdMT8dSci+RQsJ9nrXd4X+SIm07UaPkpDzDtllGF+u3mj+bcX1toECNr6DnEhSG/U4+CT3NwIBLkDWPKODEhgKOU9U3I8MRNo/fLUvAkAclNu6pv9YNtL5+kWA0UJM1QCCKyVAxA= 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=Z2R+eLd4; arc=none smtp.client-ip=192.198.163.12 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="Z2R+eLd4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735769; x=1759271769; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BqBjza3dVs7RuLhK/O/xvl0SxSraob6n8ODHpbQfFmE=; b=Z2R+eLd4KUVhB+GVCVuZtGvJy1eUSFkMM/E7dtxg2jT/+baPgYfhaBay zcaLlB/mLJwpF+D3qmb2rd8ZJRlu8utG7j6RV8Uu+MRJ1X2nX11WO63GG NNfh6LZeFySbc5dJUeIa9laaSJtwaV7OCSRwe9PBTyr/DN80OxIKcSNN3 9JA4nufp/9eEUu3K36BvlqU0d0Vb+zoAYSNwu1J68NWYZg+HUliAeaHM+ JOHJ25kV4tuecKEQ7schmdEBifkIYaSk1zcp77lu+uhvIewVe59xAn7XG 48QRC+3SH+6SpQDJBzZztVG5CY/TD5gjBnF+cerPM5UTyvknOPZNum87M Q==; X-CSE-ConnectionGUID: RoRvZsR4TLi+QIgl82U6lQ== X-CSE-MsgGUID: Wv87B7eRThyCk1UFETTGdA== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734865" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734865" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: tlEcuuCHQoueWZf29Mwz5Q== X-CSE-MsgGUID: c58JJvNIRDuBtZ0mAIXOTw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496614" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:06 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Gui-Dong Han , anthony.l.nguyen@intel.com, baijiaju1990@gmail.com, stable@vger.kernel.org, Simon Horman , Rafal Romanowski Subject: [PATCH net 03/10] ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() Date: Mon, 30 Sep 2024 15:35:50 -0700 Message-ID: <20240930223601.3137464-4-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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: Gui-Dong Han This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch. Fixes: 4035c72dc1ba ("ice: reconfig host after changing MSI-X on VF") Fixes: 4d38cb44bd32 ("ice: manage VFs MSI-X using resource tracking") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Reviewed-by: Kalesh AP --- drivers/net/ethernet/intel/ice/ice_sriov.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c index e34fe2516ccc..c2d6b2a144e9 100644 --- a/drivers/net/ethernet/intel/ice/ice_sriov.c +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c @@ -1096,8 +1096,10 @@ int ice_sriov_set_msix_vec_count(struct pci_dev *vf_dev, int msix_vec_count) return -ENOENT; vsi = ice_get_vf_vsi(vf); - if (!vsi) + if (!vsi) { + ice_put_vf(vf); return -ENOENT; + } prev_msix = vf->num_msix; prev_queues = vf->num_vf_qs; @@ -1142,8 +1144,10 @@ int ice_sriov_set_msix_vec_count(struct pci_dev *vf_dev, int msix_vec_count) vf->num_msix = prev_msix; vf->num_vf_qs = prev_queues; vf->first_vector_idx = ice_sriov_get_irqs(pf, vf->num_msix); - if (vf->first_vector_idx < 0) + if (vf->first_vector_idx < 0) { + ice_put_vf(vf); return -EINVAL; + } if (needs_rebuild) { ice_vf_reconfig_vsi(vf); From patchwork Mon Sep 30 22:35:51 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817192 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 343BB18C904 for ; Mon, 30 Sep 2024 22:36:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735771; cv=none; b=NVbzKN41YXPqKggTDRbI1HLZ+31Hm/BXLDg1LbmMrbwqqqBTN9FsllxmW7OZFzPgcSZtYDn7wsrvvCIMmdrukZfYSpkB0C3UGde+qb0b2Py7RN8KXGsavUAT8l8yYVbqoYSxDD81gLVXHgFUmDj+st1E5U0ay6MmD61sadbeLLQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735771; c=relaxed/simple; bh=H8axcbO/gVaUyc0pqgkplVS5bWiUTOAQ/YFAh27YP4k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cogmxV5op2GMGaTL+l2dhfhkUWKz+BRTGc9zstt38OFUFDoqV7/OOnCUn9Ob7SdFOHdM6FkWACPJX/aHtmNuo1ZkNlDHUaAJdCG5bcvyTQssakHXigsTG1zk8Fn/5VJedKt+d+UnEW/+YrnVarI9bpJVyBEBy15HhWP0QsJZW5g= 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=BYgkBKb4; arc=none smtp.client-ip=192.198.163.12 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="BYgkBKb4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735769; x=1759271769; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=H8axcbO/gVaUyc0pqgkplVS5bWiUTOAQ/YFAh27YP4k=; b=BYgkBKb4I+LN/7b841F1o9tEhIEX4XqAUAFuoEpgHPKaJopTyp0jS6gc g7UYZ1N5ni/emxjHecGltOTsgoivnbxbZBm1Vu0DObg6YrH/W/ElcnATd YPG8jVGW4vBYi/C4OAqqa/8ICeLIffvQCtwAKkaL77abIDWxdUaTkz/CX TW5IK08Qy+GtYCHdyMyEjeMD4ML2m58+VtB9aD4j8hAcqt3DsjxmzFLsm 9Tm6zXe2IZibKwvkv2zMI7RO6gHNQmxzwjs2cmQSM1oki3HZMAK7QukT0 AqdZDHZEt/Ksq0JtpSuXtLKFVkussapQFShCHAv8BMGs8cdNHjT90NT1H A==; X-CSE-ConnectionGUID: wtn7+thvTkyuQlGqXAANGw== X-CSE-MsgGUID: tjt2uPWDSxWDClHrlbUq6w== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734872" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734872" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: f+cQDLHSRpOEQ9N0gX8Feg== X-CSE-MsgGUID: ubYSEq+TQbuNDKaEnMMqTA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496617" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:06 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Michal Swiatkowski , anthony.l.nguyen@intel.com, wojciech.drewek@intel.com, poros@redhat.com, Piotr Tyda Subject: [PATCH net 04/10] ice: clear port vlan config during reset Date: Mon, 30 Sep 2024 15:35:51 -0700 Message-ID: <20240930223601.3137464-5-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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 Since commit 2a2cb4c6c181 ("ice: replace ice_vf_recreate_vsi() with ice_vf_reconfig_vsi()") VF VSI is only reconfigured instead of recreated. The context configuration from previous setting is still the same. If any of the config needs to be cleared it needs to be cleared explicitly. Previously there was assumption that port vlan will be cleared automatically. Now, when VSI is only reconfigured we have to do it in the code. Not clearing port vlan configuration leads to situation when the driver VSI config is different than the VSI config in HW. Traffic can't be passed after setting and clearing port vlan, because of invalid VSI config in HW. Example reproduction: > ip a a dev $(VF) $(VF_IP_ADDRESS) > ip l s dev $(VF) up > ping $(VF_IP_ADDRESS) ping is working fine here > ip link set eth5 vf 0 vlan 100 > ip link set eth5 vf 0 vlan 0 > ping $(VF_IP_ADDRESS) ping isn't working Fixes: 2a2cb4c6c181 ("ice: replace ice_vf_recreate_vsi() with ice_vf_reconfig_vsi()") Signed-off-by: Michal Swiatkowski Reviewed-by: Wojciech Drewek Tested-by: Piotr Tyda Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_vf_lib.c | 7 +++ .../net/ethernet/intel/ice/ice_vsi_vlan_lib.c | 57 +++++++++++++++++++ .../net/ethernet/intel/ice/ice_vsi_vlan_lib.h | 1 + 3 files changed, 65 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c index a69e91f88d81..749a08ccf267 100644 --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c @@ -335,6 +335,13 @@ static int ice_vf_rebuild_host_vlan_cfg(struct ice_vf *vf, struct ice_vsi *vsi) err = vlan_ops->add_vlan(vsi, &vf->port_vlan_info); } else { + /* clear possible previous port vlan config */ + err = ice_vsi_clear_port_vlan(vsi); + if (err) { + dev_err(dev, "failed to clear port VLAN via VSI parameters for VF %u, error %d\n", + vf->vf_id, err); + return err; + } err = ice_vsi_add_vlan_zero(vsi); } diff --git a/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.c b/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.c index 6e8f2aab6080..5291f2888ef8 100644 --- a/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.c @@ -787,3 +787,60 @@ int ice_vsi_clear_outer_port_vlan(struct ice_vsi *vsi) kfree(ctxt); return err; } + +int ice_vsi_clear_port_vlan(struct ice_vsi *vsi) +{ + struct ice_hw *hw = &vsi->back->hw; + struct ice_vsi_ctx *ctxt; + int err; + + ctxt = kzalloc(sizeof(*ctxt), GFP_KERNEL); + if (!ctxt) + return -ENOMEM; + + ctxt->info = vsi->info; + + ctxt->info.port_based_outer_vlan = 0; + ctxt->info.port_based_inner_vlan = 0; + + ctxt->info.inner_vlan_flags = + FIELD_PREP(ICE_AQ_VSI_INNER_VLAN_TX_MODE_M, + ICE_AQ_VSI_INNER_VLAN_TX_MODE_ALL); + if (ice_is_dvm_ena(hw)) { + ctxt->info.inner_vlan_flags |= + FIELD_PREP(ICE_AQ_VSI_INNER_VLAN_EMODE_M, + ICE_AQ_VSI_INNER_VLAN_EMODE_NOTHING); + ctxt->info.outer_vlan_flags = + FIELD_PREP(ICE_AQ_VSI_OUTER_VLAN_TX_MODE_M, + ICE_AQ_VSI_OUTER_VLAN_TX_MODE_ALL); + ctxt->info.outer_vlan_flags |= + FIELD_PREP(ICE_AQ_VSI_OUTER_TAG_TYPE_M, + ICE_AQ_VSI_OUTER_TAG_VLAN_8100); + ctxt->info.outer_vlan_flags |= + ICE_AQ_VSI_OUTER_VLAN_EMODE_NOTHING << + ICE_AQ_VSI_OUTER_VLAN_EMODE_S; + } + + ctxt->info.sw_flags2 &= ~ICE_AQ_VSI_SW_FLAG_RX_VLAN_PRUNE_ENA; + ctxt->info.valid_sections = + cpu_to_le16(ICE_AQ_VSI_PROP_OUTER_TAG_VALID | + ICE_AQ_VSI_PROP_VLAN_VALID | + ICE_AQ_VSI_PROP_SW_VALID); + + err = ice_update_vsi(hw, vsi->idx, ctxt, NULL); + if (err) { + dev_err(ice_pf_to_dev(vsi->back), "update VSI for clearing port based VLAN failed, err %d aq_err %s\n", + err, ice_aq_str(hw->adminq.sq_last_status)); + } else { + vsi->info.port_based_outer_vlan = + ctxt->info.port_based_outer_vlan; + vsi->info.port_based_inner_vlan = + ctxt->info.port_based_inner_vlan; + vsi->info.outer_vlan_flags = ctxt->info.outer_vlan_flags; + vsi->info.inner_vlan_flags = ctxt->info.inner_vlan_flags; + vsi->info.sw_flags2 = ctxt->info.sw_flags2; + } + + kfree(ctxt); + return err; +} diff --git a/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.h b/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.h index f0d84d11bd5b..12b227621a7d 100644 --- a/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.h +++ b/drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.h @@ -36,5 +36,6 @@ int ice_vsi_ena_outer_insertion(struct ice_vsi *vsi, u16 tpid); int ice_vsi_dis_outer_insertion(struct ice_vsi *vsi); int ice_vsi_set_outer_port_vlan(struct ice_vsi *vsi, struct ice_vlan *vlan); int ice_vsi_clear_outer_port_vlan(struct ice_vsi *vsi); +int ice_vsi_clear_port_vlan(struct ice_vsi *vsi); #endif /* _ICE_VSI_VLAN_LIB_H_ */ From patchwork Mon Sep 30 22:35:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817193 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 B52EA18C92A for ; Mon, 30 Sep 2024 22:36:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735771; cv=none; b=Bt2l1s5XfdehyfRZ+yUH90m17fpybKqgGi5rsPGJpWyCTKll74XKIsmWJ5ebKLNii2BDdZd809jNItJ/LD5Z0sa8OS7F6xGrd+yvnO1G5TTUfiQoCcvm1rhbW9i4kbuYrLymb2wS+v2dtwXKi+8TVRzdvqWRks1jByLkDnhwgiM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735771; c=relaxed/simple; bh=CYH6YMsYN5AMSQ4NsPFmFsVzG3bKFhKvc6NV0JWR8H8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aVT5o0msCZm/CasLKiUArJeqJeXpK+CvH1jYzItGA8gLej8HF49FBhIkUVA6xp3mFFQ2dPRCP3G8QaUomdXnvk9G415OjgVJBON5pdDhGVpVNtJomjTgdOD7NG8bjCmbrsy8hZsJ2lgvo8B2ZCVzL83cofYYYIySnHVmHeE8T0A= 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=a9dxUS2S; arc=none smtp.client-ip=192.198.163.12 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="a9dxUS2S" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735770; x=1759271770; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=CYH6YMsYN5AMSQ4NsPFmFsVzG3bKFhKvc6NV0JWR8H8=; b=a9dxUS2SuB2i4+xsEUYzcp7bHgXyxY3kEgFVc0H9OlKqEMqqGu1NDSyp SLY74+oS0q2JRkRPaPJ7R78fdqYWnocOvGrzg0TIS77x46RY94gzIjki2 7h4mXWWPezbtpoEgYC31u9k/jC5iqG2RC5S5kTkWnLNpOfqRvneKjyaRY mCaWHDL/4ECi1KiHmQxEEnzSdA9R7aqj70AR9Yf5dmWz0ipztQ8ih+w6P dl5vRoVj1e0EDhBD7MDTtcDo47edwelGhqYxZyHSYqWSTA95MfNcaYPjh Mz0Nge4ypLBS8CgwqU7FezqvpOBykiTqob6khU5L1mDwscmf5tPVCy7IK Q==; X-CSE-ConnectionGUID: AkyomwUJRNOLP/z/1rBnbg== X-CSE-MsgGUID: R+9o9EF6TDaGAve1hpxAhw== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734879" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734879" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: 4G/8+ISNSMurCrFOQXDrgg== X-CSE-MsgGUID: pGEw6KpmQW+R0bN0ye34bQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496620" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:07 -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, Larysa Zaremba , Jacob Keller , Pucha Himasekhar Reddy , Mateusz Polchlopek Subject: [PATCH net 05/10] ice: fix memleak in ice_init_tx_topology() Date: Mon, 30 Sep 2024 15:35:52 -0700 Message-ID: <20240930223601.3137464-6-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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 leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions. Fixes: cc5776fe1832 ("ice: Enable switching default Tx scheduler topology") CC: Larysa Zaremba CC: Jacob Keller CC: Pucha Himasekhar Reddy CC: Mateusz Polchlopek Signed-off-by: Przemek Kitszel Reviewed-by: Jacob Keller Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_ddp.c | 58 +++++++++++------------ drivers/net/ethernet/intel/ice/ice_ddp.h | 4 +- drivers/net/ethernet/intel/ice/ice_main.c | 8 +--- 3 files changed, 31 insertions(+), 39 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.c b/drivers/net/ethernet/intel/ice/ice_ddp.c index 953262b88a58..272fd823a825 100644 --- a/drivers/net/ethernet/intel/ice/ice_ddp.c +++ b/drivers/net/ethernet/intel/ice/ice_ddp.c @@ -31,7 +31,7 @@ static const struct ice_tunnel_type_scan tnls[] = { * Verifies various attributes of the package file, including length, format * version, and the requirement of at least one segment. */ -static enum ice_ddp_state ice_verify_pkg(struct ice_pkg_hdr *pkg, u32 len) +static enum ice_ddp_state ice_verify_pkg(const struct ice_pkg_hdr *pkg, u32 len) { u32 seg_count; u32 i; @@ -57,13 +57,13 @@ static enum ice_ddp_state ice_verify_pkg(struct ice_pkg_hdr *pkg, u32 len) /* all segments must fit within length */ for (i = 0; i < seg_count; i++) { u32 off = le32_to_cpu(pkg->seg_offset[i]); - struct ice_generic_seg_hdr *seg; + const struct ice_generic_seg_hdr *seg; /* segment header must fit */ if (len < off + sizeof(*seg)) return ICE_DDP_PKG_INVALID_FILE; - seg = (struct ice_generic_seg_hdr *)((u8 *)pkg + off); + seg = (void *)pkg + off; /* segment body must fit */ if (len < off + le32_to_cpu(seg->seg_size)) @@ -119,13 +119,13 @@ static enum ice_ddp_state ice_chk_pkg_version(struct ice_pkg_ver *pkg_ver) * * This helper function validates a buffer's header. */ -static struct ice_buf_hdr *ice_pkg_val_buf(struct ice_buf *buf) +static const struct ice_buf_hdr *ice_pkg_val_buf(const struct ice_buf *buf) { - struct ice_buf_hdr *hdr; + const struct ice_buf_hdr *hdr; u16 section_count; u16 data_end; - hdr = (struct ice_buf_hdr *)buf->buf; + hdr = (const struct ice_buf_hdr *)buf->buf; /* verify data */ section_count = le16_to_cpu(hdr->section_count); if (section_count < ICE_MIN_S_COUNT || section_count > ICE_MAX_S_COUNT) @@ -165,8 +165,8 @@ static struct ice_buf_table *ice_find_buf_table(struct ice_seg *ice_seg) * unexpected value has been detected (for example an invalid section count or * an invalid buffer end value). */ -static struct ice_buf_hdr *ice_pkg_enum_buf(struct ice_seg *ice_seg, - struct ice_pkg_enum *state) +static const struct ice_buf_hdr *ice_pkg_enum_buf(struct ice_seg *ice_seg, + struct ice_pkg_enum *state) { if (ice_seg) { state->buf_table = ice_find_buf_table(ice_seg); @@ -1800,9 +1800,9 @@ int ice_update_pkg(struct ice_hw *hw, struct ice_buf *bufs, u32 count) * success it returns a pointer to the segment header, otherwise it will * return NULL. */ -static struct ice_generic_seg_hdr * +static const struct ice_generic_seg_hdr * ice_find_seg_in_pkg(struct ice_hw *hw, u32 seg_type, - struct ice_pkg_hdr *pkg_hdr) + const struct ice_pkg_hdr *pkg_hdr) { u32 i; @@ -1813,11 +1813,9 @@ ice_find_seg_in_pkg(struct ice_hw *hw, u32 seg_type, /* Search all package segments for the requested segment type */ for (i = 0; i < le32_to_cpu(pkg_hdr->seg_count); i++) { - struct ice_generic_seg_hdr *seg; + const struct ice_generic_seg_hdr *seg; - seg = (struct ice_generic_seg_hdr - *)((u8 *)pkg_hdr + - le32_to_cpu(pkg_hdr->seg_offset[i])); + seg = (void *)pkg_hdr + le32_to_cpu(pkg_hdr->seg_offset[i]); if (le32_to_cpu(seg->seg_type) == seg_type) return seg; @@ -2354,12 +2352,12 @@ ice_get_set_tx_topo(struct ice_hw *hw, u8 *buf, u16 buf_size, * * Return: zero when update was successful, negative values otherwise. */ -int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len) +int ice_cfg_tx_topo(struct ice_hw *hw, const void *buf, u32 len) { - u8 *current_topo, *new_topo = NULL; - struct ice_run_time_cfg_seg *seg; - struct ice_buf_hdr *section; - struct ice_pkg_hdr *pkg_hdr; + u8 *new_topo = NULL, *topo __free(kfree) = NULL; + const struct ice_run_time_cfg_seg *seg; + const struct ice_buf_hdr *section; + const struct ice_pkg_hdr *pkg_hdr; enum ice_ddp_state state; u16 offset, size = 0; u32 reg = 0; @@ -2375,15 +2373,13 @@ int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len) return -EOPNOTSUPP; } - current_topo = kzalloc(ICE_AQ_MAX_BUF_LEN, GFP_KERNEL); - if (!current_topo) + topo = kzalloc(ICE_AQ_MAX_BUF_LEN, GFP_KERNEL); + if (!topo) return -ENOMEM; - /* Get the current Tx topology */ - status = ice_get_set_tx_topo(hw, current_topo, ICE_AQ_MAX_BUF_LEN, NULL, - &flags, false); - - kfree(current_topo); + /* Get the current Tx topology flags */ + status = ice_get_set_tx_topo(hw, topo, ICE_AQ_MAX_BUF_LEN, NULL, &flags, + false); if (status) { ice_debug(hw, ICE_DBG_INIT, "Get current topology is failed\n"); @@ -2419,7 +2415,7 @@ int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len) goto update_topo; } - pkg_hdr = (struct ice_pkg_hdr *)buf; + pkg_hdr = (const struct ice_pkg_hdr *)buf; state = ice_verify_pkg(pkg_hdr, len); if (state) { ice_debug(hw, ICE_DBG_INIT, "Failed to verify pkg (err: %d)\n", @@ -2428,7 +2424,7 @@ int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len) } /* Find runtime configuration segment */ - seg = (struct ice_run_time_cfg_seg *) + seg = (const struct ice_run_time_cfg_seg *) ice_find_seg_in_pkg(hw, SEGMENT_TYPE_ICE_RUN_TIME_CFG, pkg_hdr); if (!seg) { ice_debug(hw, ICE_DBG_INIT, "5 layer topology segment is missing\n"); @@ -2461,8 +2457,10 @@ int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len) return -EIO; } - /* Get the new topology buffer */ - new_topo = ((u8 *)section) + offset; + /* Get the new topology buffer, reuse current topo copy mem */ + static_assert(ICE_PKG_BUF_SIZE == ICE_AQ_MAX_BUF_LEN); + new_topo = topo; + memcpy(new_topo, (u8 *)section + offset, size); update_topo: /* Acquire global lock to make sure that set topology issued diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.h b/drivers/net/ethernet/intel/ice/ice_ddp.h index 97f272317475..79551da2a4b0 100644 --- a/drivers/net/ethernet/intel/ice/ice_ddp.h +++ b/drivers/net/ethernet/intel/ice/ice_ddp.h @@ -438,7 +438,7 @@ struct ice_pkg_enum { u32 buf_idx; u32 type; - struct ice_buf_hdr *buf; + const struct ice_buf_hdr *buf; u32 sect_idx; void *sect; u32 sect_type; @@ -467,6 +467,6 @@ ice_pkg_enum_entry(struct ice_seg *ice_seg, struct ice_pkg_enum *state, void *ice_pkg_enum_section(struct ice_seg *ice_seg, struct ice_pkg_enum *state, u32 sect_type); -int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len); +int ice_cfg_tx_topo(struct ice_hw *hw, const void *buf, u32 len); #endif diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index eeb48cc48e08..fbab72fab79c 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -4536,16 +4536,10 @@ ice_init_tx_topology(struct ice_hw *hw, const struct firmware *firmware) u8 num_tx_sched_layers = hw->num_tx_sched_layers; struct ice_pf *pf = hw->back; struct device *dev; - u8 *buf_copy; int err; dev = ice_pf_to_dev(pf); - /* ice_cfg_tx_topo buf argument is not a constant, - * so we have to make a copy - */ - buf_copy = kmemdup(firmware->data, firmware->size, GFP_KERNEL); - - err = ice_cfg_tx_topo(hw, buf_copy, firmware->size); + err = ice_cfg_tx_topo(hw, firmware->data, firmware->size); if (!err) { if (hw->num_tx_sched_layers > num_tx_sched_layers) dev_info(dev, "Tx scheduling layers switching feature disabled\n"); From patchwork Mon Sep 30 22:35:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817194 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 A5E441946A9 for ; Mon, 30 Sep 2024 22:36:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735772; cv=none; b=I6/ca8HbD6n+mt9FShEcCIK3I2e5eh6RuQz/COd2c073Nol4RKSuXIEl7UEe+Ajan610W7T5stq6nym7nkaho++qJGODcMMUIvdlCiLYZzVtwWqLMUKh611Xmct2yV0Sm+jcCxlVvemVhzxdVsln3i0mM6HLbtzPlPcQzC9tCr0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735772; c=relaxed/simple; bh=a98lEoJCvRiHq1dJDmAHiDNwEAUann7GHB0f2aYjLoc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bPgwCPiebWZFPPQFPpUsTps4Kc0SVbPxYyjSb8NNrkO+jbCFl0vU489SoSEuCniwydE+Tl7pY4oo6ZRiab1B6KDPbeQqOxUL2ZtuOdHaHxrs974+xGhUQgJdItBolrNfTXmVVxRl6xZpQPu0FHbDyEBZWsYstc45Zw71FVgtguU= 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=K4aaStZ/; arc=none smtp.client-ip=192.198.163.12 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="K4aaStZ/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735770; x=1759271770; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=a98lEoJCvRiHq1dJDmAHiDNwEAUann7GHB0f2aYjLoc=; b=K4aaStZ/RtRnuzYEKizNlulovBAMx0hlnf1hRYTZslhoJIpwA7a81jTK tEw7Ch5Uv4PQEEUoculqWRPJCy7e2RX3D3VeReWFFV54wrvyO+VZYRFPM L6iu5uhFFCXWXu+t0rJsQNUjEEcbLbZ8G5sHqCL2eiaolMul/HdXBoD/U BVE/Z/pYS4hD6NRGMa/nXT/mBAjxgEYXEvBUN0O/pUIhCRsxMDo8N1NUH kX16XqPJk4LkyJfvi64CXW5N93NpZ+029SfqXe9DzXtXbZ6ALpyBlZSrN fiRMVDwthMDD+Oj1Jlokuw7hr1/x2IWj9IVPSnYwyJ2qzitcD8GR9jgA5 Q==; X-CSE-ConnectionGUID: neZvA1keSpysTBFAD6cYmg== X-CSE-MsgGUID: nJ0lN4osSsGDTD4al5vaqg== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734882" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734882" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: hmJmE5B2QmCuUH38SVhxGg== X-CSE-MsgGUID: A2IT3aRgRmOPQe+mnp8drA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496623" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:07 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Arkadiusz Kubalewski , anthony.l.nguyen@intel.com, vadim.fedorenko@linux.dev, jiri@resnulli.us, Aleksandr Loktionov , Paul Menzel , Pucha Himasekhar Reddy Subject: [PATCH net 06/10] ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins Date: Mon, 30 Sep 2024 15:35:53 -0700 Message-ID: <20240930223601.3137464-7-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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: Arkadiusz Kubalewski Currently the user may request DPLL_PIN_STATE_SELECTABLE for an output pin, and this would actually set the DISCONNECTED state instead. It doesn't make any sense. SELECTABLE is valid only in case of input pins (on AUTOMATIC type dpll), where dpll itself would select best valid input. For the output pin only CONNECTED/DISCONNECTED are expected. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Signed-off-by: Arkadiusz Kubalewski Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_dpll.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c index 8b6dc4d54fdc..74c0e7319a4c 100644 --- a/drivers/net/ethernet/intel/ice/ice_dpll.c +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c @@ -656,6 +656,8 @@ ice_dpll_output_state_set(const struct dpll_pin *pin, void *pin_priv, struct ice_dpll_pin *p = pin_priv; struct ice_dpll *d = dpll_priv; + if (state == DPLL_PIN_STATE_SELECTABLE) + return -EINVAL; if (!enable && p->state[d->dpll_idx] == DPLL_PIN_STATE_DISCONNECTED) return 0; From patchwork Mon Sep 30 22:35:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817195 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 362511991B1 for ; Mon, 30 Sep 2024 22:36:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735773; cv=none; b=LrwjbOv0U4qqo5l9KLy/1Hf6xBxiXmLosvPlFn4s266bYSt84k43CtQzLyNme9+LqzURjf+8U8QVhO8BRnaodZVWfv7aZCkeBriAT1fS2c8p+8GGci2Yyr1wPrDhcfxbyhtKOq+jRhyNvNLQDkRyn7Q/o6bg8wf9eJvyc9C/NPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735773; c=relaxed/simple; bh=XDfzUmMR9gfBvOMfEefkdkONMEQInv3V5Rxu4mIhN20=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mBD+7G6H3MN7ySTBmXIYXBQR35LPZEEuYYllzdihf7OQ7OkOZa58gf9z8Z8U+7G2OLENcX4lKlVEv4sqpo7jNRKWLDQQRMLD8qmLZdkgJgSEoZ+VIKizKZAyg3ZGAEICQ6hKJs7ziQOHlbqGAfY2uPh2s+xyY1jqb9ZMaJuI6os= 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=V8TEk+Mn; arc=none smtp.client-ip=192.198.163.12 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="V8TEk+Mn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735771; x=1759271771; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=XDfzUmMR9gfBvOMfEefkdkONMEQInv3V5Rxu4mIhN20=; b=V8TEk+MnHe0zpZeMc+OeywA1dVcDOOYlrx8uqLe6YqyWth6qj3/5KnO5 lhFwqSsgyHJy8RnJ3BJKoM2Jc3bHJkVoikmjLyRnyTgPTtyhbpmBaVqsG LwePhoT7w7x4BGJ0JgC7g2OfRDnQDknrMa3lxSPNPnJcpQR96O+B1uHJ5 QqEAk6W7xqHoWGkM3sM8+dB2ngqpth2/Qal1uXqtb8GXT6BAliUTnPdGU JEVkwuglCXfeeyDYQyR1CPrcdeeYyK4/LiQ+wpJglIQGBASaCKDAJQAx4 Uk69ybkf8CPnCUDkVgwsTbv+6N4DHBtUbrnuDeG3zirlgV5el6fyCpdK1 A==; X-CSE-ConnectionGUID: tWO4PFlQRSi95S0gyUnMMw== X-CSE-MsgGUID: MquZxhBiSK2Er7U49t66/g== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734892" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734892" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: aJUwVPFrSImK6L1zXyH94A== X-CSE-MsgGUID: r+cMTNpvSiqpiGmDnQTbWg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496626" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:07 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Dave Ertman , anthony.l.nguyen@intel.com, Przemek Kitszel , Jacob Keller , Pucha Himasekhar Reddy Subject: [PATCH net 07/10] ice: fix VLAN replay after reset Date: Mon, 30 Sep 2024 15:35:54 -0700 Message-ID: <20240930223601.3137464-8-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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: Dave Ertman There is a bug currently when there are more than one VLAN defined and any reset that affects the PF is initiated, after the reset rebuild no traffic will pass on any VLAN but the last one created. This is caused by the iteration though the VLANs during replay each clearing the vsi_map bitmap of the VSI that is being replayed. The problem is that during rhe replay, the pointer to the vsi_map bitmap is used by each successive vlan to determine if it should be replayed on this VSI. The logic was that the replay of the VLAN would replace the bit in the map before the next VLAN would iterate through. But, since the replay copies the old bitmap pointer to filt_replay_rules and creates a new one for the recreated VLANS, it does not do this, and leaves the old bitmap broken to be used to replay the remaining VLANs. Since the old bitmap will be cleaned up in post replay cleanup, there is no need to alter it and break following VLAN replay, so don't clear the bit. Fixes: 334cb0626de1 ("ice: Implement VSI replay framework") Reviewed-by: Przemek Kitszel Signed-off-by: Dave Ertman Reviewed-by: Jacob Keller Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_switch.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index 79d91e95358c..0e740342e294 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -6322,8 +6322,6 @@ ice_replay_vsi_fltr(struct ice_hw *hw, u16 vsi_handle, u8 recp_id, if (!itr->vsi_list_info || !test_bit(vsi_handle, itr->vsi_list_info->vsi_map)) continue; - /* Clearing it so that the logic can add it back */ - clear_bit(vsi_handle, itr->vsi_list_info->vsi_map); f_entry.fltr_info.vsi_handle = vsi_handle; f_entry.fltr_info.fltr_act = ICE_FWD_TO_VSI; /* update the src in case it is VSI num */ From patchwork Mon Sep 30 22:35:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817196 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 0F95319AA57 for ; Mon, 30 Sep 2024 22:36:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735773; cv=none; b=OqO0hx2L2tQ3uH1QMj/MkSpLstUifXQeDqjfzgRG2bajLY+f/6AipGqx3TuXO/s2yUMoAMcIVyG+klBSlEB1cRd+kUp7aSZMcWZ3BPurFKMWnSHx1nyUnSUY8k+ivHmwu8ZMUTfs60rkEwE3sAJTFnHaPhWZDxhO7NiPHWdJ4kY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735773; c=relaxed/simple; bh=xIrtZfFvS4XenpiTX/WFZf55dVsU48q+QRt9toQF/bo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XNbqnbLReFBiUnIAAVegx+ow14tNC58kdrAcNvmtKBnH3ZAfMv2Eo1U+cr99lFvuY+h5WKA3i4QIVLbfGFtlB3dbbwmksIfC+ZsHN7UV1cEPM8wEaCXB69eRL1Kcozhlzrpns3nIuZvYvmOhTEY+BCzIRzV4c8MCEarVRWxXd7Q= 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=JhZwESEX; arc=none smtp.client-ip=192.198.163.12 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="JhZwESEX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735772; x=1759271772; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=xIrtZfFvS4XenpiTX/WFZf55dVsU48q+QRt9toQF/bo=; b=JhZwESEX+SwsNU2caIvb82yJKbR4IIPx2fxOgOtGoQiqM1et//kmXIt9 PAloVbxJgajv4Zgaa0O7Fe/vMWFbjfLxhqvmDl6oOFmb/UZTM+hDkNMIN 92uyOktgM0EjE7Y2tvq/XSvY4jIY217atI9eCWfefAbNbLaKy+BhJE7Pc 3dzujgZyJ2ltFyR8cMJ4eJHhY+IDY8lJA+8fpag4wh5C2H7o80SbVIDUB Pt0QLNRR5AJJnvvYAKlKTNUZclUvR9vzyfD8+hvLBRPopqXzmKxTItoWU tAIcSYxIU1mX3f4RbHJsoNu7ciku6XdmT5dk/AVqVijKJAwuCmsnBr3ys g==; X-CSE-ConnectionGUID: 4tLm/10GSnuj8reacjBYfA== X-CSE-MsgGUID: XCzjcK+mQxWDXYvxv+yFeQ== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734896" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734896" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: bZ9i+JIUTFqEYskGNMWigg== X-CSE-MsgGUID: NgCcMIYESae3++jtrU6IJA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496630" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:07 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Ahmed Zaki , anthony.l.nguyen@intel.com, willemb@google.com, Przemek Kitszel , Simon Horman , Krishneil Singh Subject: [PATCH net 08/10] idpf: fix VF dynamic interrupt ctl register initialization Date: Mon, 30 Sep 2024 15:35:55 -0700 Message-ID: <20240930223601.3137464-9-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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: Ahmed Zaki The VF's dynamic interrupt ctl "dyn_ctl_intrvl_s" is not initialized in idpf_vf_intr_reg_init(). This resulted in the following UBSAN error whenever a VF is created: [ 564.345655] UBSAN: shift-out-of-bounds in drivers/net/ethernet/intel/idpf/idpf_txrx.c:3654:10 [ 564.345663] shift exponent 4294967295 is too large for 32-bit type 'int' [ 564.345671] CPU: 33 UID: 0 PID: 2458 Comm: NetworkManager Not tainted 6.11.0-rc4+ #1 [ 564.345678] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C6200.86B.0027.P10.2201070222 01/07/2022 [ 564.345683] Call Trace: [ 564.345688] [ 564.345693] dump_stack_lvl+0x91/0xb0 [ 564.345708] __ubsan_handle_shift_out_of_bounds+0x16b/0x320 [ 564.345730] idpf_vport_intr_update_itr_ena_irq.cold+0x13/0x39 [idpf] [ 564.345755] ? __pfx_idpf_vport_intr_update_itr_ena_irq+0x10/0x10 [idpf] [ 564.345771] ? static_obj+0x95/0xd0 [ 564.345782] ? lockdep_init_map_type+0x1a5/0x800 [ 564.345794] idpf_vport_intr_ena+0x5ef/0x9f0 [idpf] [ 564.345814] idpf_vport_open+0x2cc/0x1240 [idpf] [ 564.345837] idpf_open+0x6d/0xc0 [idpf] [ 564.345850] __dev_open+0x241/0x420 Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport") Reviewed-by: Przemek Kitszel Signed-off-by: Ahmed Zaki Reviewed-by: Simon Horman Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen Reviewed-by: Kalesh AP --- drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c b/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c index 99b8dbaf4225..aad62e270ae4 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c +++ b/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c @@ -99,6 +99,7 @@ static int idpf_vf_intr_reg_init(struct idpf_vport *vport) intr->dyn_ctl_intena_m = VF_INT_DYN_CTLN_INTENA_M; intr->dyn_ctl_intena_msk_m = VF_INT_DYN_CTLN_INTENA_MSK_M; intr->dyn_ctl_itridx_s = VF_INT_DYN_CTLN_ITR_INDX_S; + intr->dyn_ctl_intrvl_s = VF_INT_DYN_CTLN_INTERVAL_S; intr->dyn_ctl_wb_on_itr_m = VF_INT_DYN_CTLN_WB_ON_ITR_M; spacing = IDPF_ITR_IDX_SPACING(reg_vals[vec_id].itrn_index_spacing, From patchwork Mon Sep 30 22:35:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817197 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 F3AC51A0BCB; Mon, 30 Sep 2024 22:36:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735774; cv=none; b=L/5zkkrmRB0tF+cXULPByZQhHCkATSUATS33YOzcGsK4ThvzVHrjOiRoEeDadgaDNfXbG1jQhPaJH2HIR3O+y7OaZ9/OR+NDm9lUkU2XM+dEIK7UaCPj5F2oJQ/3PJwH1H2wXJ/NzeX+FfozFpF7NS34nzfZCvHqIOuMR4t9dlo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735774; c=relaxed/simple; bh=EQagrq8iEetD3afIvCwI9WqOrnNYF4kt2DFH6ckk9WA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jzYXK++XggQeqIVSt68BCkLAc/AXeZHnpuuyyVrKCN7NN9wvOaLNiPrns7GLuH66wQf0ptuV0eil+3P1alWPcjkcSBv+TMHhvlaW4LL+fbw9o59n7synk9b5GqpGGencnHTMkfTOk9msmRQGqPGhfGQYjQeIktzCnJHnqfgn9A8= 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=cJhmxLRp; arc=none smtp.client-ip=192.198.163.12 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="cJhmxLRp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735773; x=1759271773; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=EQagrq8iEetD3afIvCwI9WqOrnNYF4kt2DFH6ckk9WA=; b=cJhmxLRpciIdse/OInFw+vCXiRe4siYmqy7UR/pcI8yKCNK4xng2uFLh Y8376W62VOdPtjsvBngQTXg6Dtw/ZET1S1penNNdlNlb1XBI0UFYkRsGI V0pKHj3Gzt7Y64TgA6/cf4p11IgJHVOAQ9PUnOeMTPmg6qLGmjszoS8vH WKEugBAOuYqGl3XXKWbCsRFJYUHaJVdrZqhU0nMBBuWMnQkLPrQcOxlDW W6C5xurV4+GTPRoeRDFqHz3jVD9HtpKLkVqFPOGs0ZTdJHOXGYGVGcns7 2lmVZl3hXunPtZ+IevlSgy3zfwk5nDd49uomTeveedMG7xBAmVvoUZwkr Q==; X-CSE-ConnectionGUID: UQmJfDO9RnSpW5vp7etqyQ== X-CSE-MsgGUID: Hu7f0tbQRRS907As69k8pQ== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734900" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734900" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:07 -0700 X-CSE-ConnectionGUID: vu0kw/eISsCfeXJP1yFqYg== X-CSE-MsgGUID: Nh9hUM+VRdCSWL+BqRaMFQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496635" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:07 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Joshua Hay , anthony.l.nguyen@intel.com, aleksander.lobakin@intel.com, milena.olech@intel.com, stable@vger.kernel.org, Przemek Kitszel , Krishneil Singh Subject: [PATCH net 09/10] idpf: use actual mbx receive payload length Date: Mon, 30 Sep 2024 15:35:56 -0700 Message-ID: <20240930223601.3137464-10-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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: Joshua Hay When a mailbox message is received, the driver is checking for a non 0 datalen in the controlq descriptor. If it is valid, the payload is attached to the ctlq message to give to the upper layer. However, the payload response size given to the upper layer was taken from the buffer metadata which is _always_ the max buffer size. This meant the API was returning 4K as the payload size for all messages. This went unnoticed since the virtchnl exchange response logic was checking for a response size less than 0 (error), not less than exact size, or not greater than or equal to the max mailbox buffer size (4K). All of these checks will pass in the success case since the size provided is always 4K. However, this breaks anyone that wants to validate the exact response size. Fetch the actual payload length from the value provided in the descriptor data_len field (instead of the buffer metadata). Unfortunately, this means we lose some extra error parsing for variable sized virtchnl responses such as create vport and get ptypes. However, the original checks weren't really helping anyways since the size was _always_ 4K. Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Cc: stable@vger.kernel.org # 6.9+ Signed-off-by: Joshua Hay Reviewed-by: Przemek Kitszel Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index 70986e12da28..3c0f97650d72 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c @@ -666,7 +666,7 @@ idpf_vc_xn_forward_reply(struct idpf_adapter *adapter, if (ctlq_msg->data_len) { payload = ctlq_msg->ctx.indirect.payload->va; - payload_size = ctlq_msg->ctx.indirect.payload->size; + payload_size = ctlq_msg->data_len; } xn->reply_sz = payload_size; @@ -1295,10 +1295,6 @@ int idpf_send_create_vport_msg(struct idpf_adapter *adapter, err = reply_sz; goto free_vport_params; } - if (reply_sz < IDPF_CTLQ_MAX_BUF_LEN) { - err = -EIO; - goto free_vport_params; - } return 0; @@ -2602,9 +2598,6 @@ int idpf_send_get_rx_ptype_msg(struct idpf_vport *vport) if (reply_sz < 0) return reply_sz; - if (reply_sz < IDPF_CTLQ_MAX_BUF_LEN) - return -EIO; - ptypes_recvd += le16_to_cpu(ptype_info->num_ptypes); if (ptypes_recvd > max_ptype) return -EINVAL; From patchwork Mon Sep 30 22:35:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817198 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 A9F7E1A0BF1 for ; Mon, 30 Sep 2024 22:36:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735775; cv=none; b=IhyLJUyIFItSG9GvwaqGRKRlZYUlIKt/A9ujstGDf/QV88/aAi3aODn/d8AHHF9GzmMVUEQLWY53qdNRENdtsjVm99JLr7r5jV9x410dZk2a1FK2YZatd7PSYBKQ3l/l03rZry26q7KSd1mF5XebS2+7ZeNlQg0mIKKWGjvybPs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735775; c=relaxed/simple; bh=jTFrk3GXC6E7WD7EUPwBnIp9hXF7LXVwQkJv/eQOLAQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PA0GktuwjBQlSqiSDJx63NTctVdlQ1HhJhSJeshrx31cUKSlqJawWfjCIWWysjFFxAVjCQAIhBVdEx1JiqC2bV1V98y3z4e41eOqYoiO+HBeI2h+v4F5P4/X1stlyPrSWhk4MUmAPhUh7oBiPNyikBjVEHXbPHqGQXRZdNfZSjk= 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=cl4pFBxs; arc=none smtp.client-ip=192.198.163.12 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="cl4pFBxs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735773; x=1759271773; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jTFrk3GXC6E7WD7EUPwBnIp9hXF7LXVwQkJv/eQOLAQ=; b=cl4pFBxso8ltn3a9Q/slAB+rvD4XK7+dAr0L8AeAolLz7PWGwv713vha VN7j1W7U1N8rmLZbWIa3LsDvxsoPZ9DqNxApcq46wndb0iZy5WZavm48m Es/w/q+eQa2WWIZRkwE4p7q6hdffNn/erX10pvVqFg/Tk69FpsbjRqypA 6n1b+UwdpfvwqQic8ReC1eXHl+5XdzbSeiZ4YTjkrQCyws9RR+0rdS6a1 brCciGBd3AnMl2BlA3cVbcFRtcU5WyoHd3QWBnJAO3xDXxBpy+AkQ6Ddr xKX5Qi4InYuRen7H9s36aQx8e7As9vFpbaLzqvHcSOqgUFC9oRdnUgWIJ g==; X-CSE-ConnectionGUID: Apt+F6Z9Tj6gck+eVmP0+Q== X-CSE-MsgGUID: 9569TSv/RGmTOxttMw3imQ== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734905" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734905" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:07 -0700 X-CSE-ConnectionGUID: seVfIK18T/2zDG8ShsRriw== X-CSE-MsgGUID: usYCBkK/RgqQo76Wc6zU+w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496639" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:07 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Larysa Zaremba , anthony.l.nguyen@intel.com, Przemek Kitszel , Krishneil Singh Subject: [PATCH net 10/10] idpf: deinit virtchnl transaction manager after vport and vectors Date: Mon, 30 Sep 2024 15:35:57 -0700 Message-ID: <20240930223601.3137464-11-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-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 When the device is removed, idpf is supposed to make certain virtchnl requests e.g. VIRTCHNL2_OP_DEALLOC_VECTORS and VIRTCHNL2_OP_DESTROY_VPORT. However, this does not happen due to the referenced commit introducing virtchnl transaction manager and placing its deinitialization before those messages are sent. Then the sending is impossible due to no transactions being available. Lack of cleanup can lead to the FW becoming unresponsive from e.g. unloading-loading the driver and creating-destroying VFs afterwards. Move transaction manager deinitialization to after other virtchnl-related cleanup is done. Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Reviewed-by: Przemek Kitszel Signed-off-by: Larysa Zaremba Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index 3c0f97650d72..15c00a01f1c0 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c @@ -3081,9 +3081,9 @@ void idpf_vc_core_deinit(struct idpf_adapter *adapter) if (!test_bit(IDPF_VC_CORE_INIT, adapter->flags)) return; - idpf_vc_xn_shutdown(adapter->vcxn_mngr); idpf_deinit_task(adapter); idpf_intr_rel(adapter); + idpf_vc_xn_shutdown(adapter->vcxn_mngr); cancel_delayed_work_sync(&adapter->serv_task); cancel_delayed_work_sync(&adapter->mbx_task);