From patchwork Mon Nov 4 22:36:29 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13862192 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 182231F755C for ; Mon, 4 Nov 2024 22:36:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759806; cv=none; b=MiA93/MAmJcBi4clH73gycg2a4/3F+tUpa46vzZrJDyb6FmSbDpDSHVLWbxjyUeyRUnBFykxOPjr3zmyhu35H7obRY/08fwkyZ0J2l2A6z/XIc1fqKcbBJeO1Yx8nboiQnw6fv/iDqSz1+luCC/2T8QrTyUYdFE1wxv5w0FLO6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759806; c=relaxed/simple; bh=fK5GtXswCCfWw3ynsynFvA5cf0rRYbuXSvMeNJZ+8UI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nG9tGdHaOPcJGdtEtHTi2AqxWttb4m4amQxr3iIHAFrs+zcoy7gPoV5vJVKX0mQ7afqkU9eoE+2p9o2V9/LvkRgDxBx/Q+jgp2j/HS5MJa+IoatmKVgbiHurYg0wwo6kyhOQWgMGm24Fv34ctn5Q/JRXzEwtJ7PAvV3qDGo/Xa0= 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=ZqRzCaEs; arc=none smtp.client-ip=192.198.163.19 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="ZqRzCaEs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730759805; x=1762295805; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=fK5GtXswCCfWw3ynsynFvA5cf0rRYbuXSvMeNJZ+8UI=; b=ZqRzCaEsRKMf4tNPJF/wUADIbVbzHNw7oIV6SiY3m/TkKN/OUPn3gLCq FLIlFuR8u2Cl9JlaUhinizJJU+HPZ9aY9UVdaGmpKy75kN5T2D1KBpH5O pxFKOPukk3qpeA8YsG6nnElZdhAe4/4TbVLbjIXPUeiljgN8XTRtSPvPK RR7o92AO3lQ0/0s5+f4CmnUlwPGNs9/4R7DA4aoG4kN112ZgOFE3o8vAx JlTsX+9vv15pzwC/4P/qIwfQkyC6MtGIWyyM1vLiZyoaA+Yc4UBAdcXVn JuS2u2bpjvrJr7H0bRwapkeYONMvADqSbhriUDA+z0rQ8Ak4tdaEOY80P g==; X-CSE-ConnectionGUID: vDAQseVATyKYxmgX1BTJMw== X-CSE-MsgGUID: IbBZyAyGSP6meANCWZ8SwA== X-IronPort-AV: E=McAfee;i="6700,10204,11246"; a="29901638" X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="29901638" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2024 14:36:43 -0800 X-CSE-ConnectionGUID: 58dMR06KTNWRwm04BhM5bQ== X-CSE-MsgGUID: M/Iw3kQ4QRmJ0vyM3g01DA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="83316973" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa006.fm.intel.com with ESMTP; 04 Nov 2024 14:36:43 -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@linux.intel.com, Paul Menzel , Sujai Buvaneswaran Subject: [PATCH net 1/6] ice: Fix use after free during unload with ports in bridge Date: Mon, 4 Nov 2024 14:36:29 -0800 Message-ID: <20241104223639.2801097-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241104223639.2801097-1-anthony.l.nguyen@intel.com> References: <20241104223639.2801097-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 Unloading the ice driver while switchdev port representors are added to a bridge can lead to kernel panic. Reproducer: modprobe ice devlink dev eswitch set $PF1_PCI mode switchdev ip link add $BR type bridge ip link set $BR up echo 2 > /sys/class/net/$PF1/device/sriov_numvfs sleep 2 ip link set $PF1 master $BR ip link set $VF1_PR master $BR ip link set $VF2_PR master $BR ip link set $PF1 up ip link set $VF1_PR up ip link set $VF2_PR up ip link set $VF1 up rmmod irdma ice When unloading the driver, ice_eswitch_detach() is eventually called as part of VF freeing. First, it removes a port representor from xarray, then unregister_netdev() is called (via repr->ops.rem()), finally representor is deallocated. The problem comes from the bridge doing its own deinit at the same time. unregister_netdev() triggers a notifier chain, resulting in ice_eswitch_br_port_deinit() being called. It should set repr->br_port = NULL, but this does not happen since repr has already been removed from xarray and is not found. Regardless, it finishes up deallocating br_port. At this point, repr is still not freed and an fdb event can happen, in which ice_eswitch_br_fdb_event_work() takes repr->br_port and tries to use it, which causes a panic (use after free). Note that this only happens with 2 or more port representors added to the bridge, since with only one representor port, the bridge deinit is slightly different (ice_eswitch_br_port_deinit() is called via ice_eswitch_br_ports_flush(), not ice_eswitch_br_port_unlink()). Trace: Oops: general protection fault, probably for non-canonical address 0xf129010fd1a93284: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x8948287e8d499420-0x8948287e8d499427] (...) Workqueue: ice_bridge_wq ice_eswitch_br_fdb_event_work [ice] RIP: 0010:__rht_bucket_nested+0xb4/0x180 (...) Call Trace: (...) ice_eswitch_br_fdb_find+0x3fa/0x550 [ice] ? __pfx_ice_eswitch_br_fdb_find+0x10/0x10 [ice] ice_eswitch_br_fdb_event_work+0x2de/0x1e60 [ice] ? __schedule+0xf60/0x5210 ? mutex_lock+0x91/0xe0 ? __pfx_ice_eswitch_br_fdb_event_work+0x10/0x10 [ice] ? ice_eswitch_br_update_work+0x1f4/0x310 [ice] (...) A workaround is available: brctl setageing $BR 0, which stops the bridge from adding fdb entries altogether. Change the order of operations in ice_eswitch_detach(): move the call to unregister_netdev() before removing repr from xarray. This way repr->br_port will be correctly set to NULL in ice_eswitch_br_port_deinit(), preventing a panic. Fixes: fff292b47ac1 ("ice: add VF representors one by one") Reviewed-by: Michal Swiatkowski Reviewed-by: Paul Menzel Signed-off-by: Marcin Szycik Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_eswitch.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c b/drivers/net/ethernet/intel/ice/ice_eswitch.c index c0b3e70a7ea3..fb527434b58b 100644 --- a/drivers/net/ethernet/intel/ice/ice_eswitch.c +++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c @@ -552,13 +552,14 @@ int ice_eswitch_attach_sf(struct ice_pf *pf, struct ice_dynamic_port *sf) static void ice_eswitch_detach(struct ice_pf *pf, struct ice_repr *repr) { ice_eswitch_stop_reprs(pf); + repr->ops.rem(repr); + xa_erase(&pf->eswitch.reprs, repr->id); if (xa_empty(&pf->eswitch.reprs)) ice_eswitch_disable_switchdev(pf); ice_eswitch_release_repr(pf, repr); - repr->ops.rem(repr); ice_repr_destroy(repr); if (xa_empty(&pf->eswitch.reprs)) { From patchwork Mon Nov 4 22:36:30 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13862193 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 A1BEC1FCC7C for ; Mon, 4 Nov 2024 22:36:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759807; cv=none; b=fdEsw4k3zF7RXN9+osoPYoFY86nyydKHGfn70bweW9Q81Tv640JHNb/2VVCLhRvZqIo9aKgn0s4ARYGV8AMWpN1wpUMKuOBqfi+yaLhazsGGdmI8pplUX83OBlOIBvO77pqMUUSeWqSU+iFUXJoEIfHZ28B9UcY8aTv+mxowq3M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759807; c=relaxed/simple; bh=+ubHQu77J9I3GlXsjmZmJQOw0UAuDkumxoVZJ6X/ImE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X1KYJqIdFHNU3GmkzhQHlDNH7s9Z0x7CrqyiLhnP7gPbwMyBoarqgnoEHfhEQnW7iG+wHrdWV1qeYpRPZaNdTDFGuq06eZ6Ltx+nMXZbQYjahauebcbxTWOl3KYd8BOEJ7uNyqTXWJ//MVQ+WUSEnAr1ZgwxUYi6aWIsB5PFLLE= 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=iMXdAwmY; arc=none smtp.client-ip=192.198.163.19 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="iMXdAwmY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730759805; x=1762295805; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+ubHQu77J9I3GlXsjmZmJQOw0UAuDkumxoVZJ6X/ImE=; b=iMXdAwmYhmMOVmFUNh36Ywrtg9a/pMlHFEwhQDmT7a/mEdZnLGdHag6Q T2fWc9HzzGLs+vUeBnBw1expQslj+XfabsY/NLiGyBATw9mEwr4VW4Eq/ SF21xDn685jKl9wxofvMpnR8DykmCy6AfFlJYAXaEmcqeOfkgzcgWAdJC 7iHbisfCqwukB9PRjfeufT//vULTKY9+V8hvrQN4HOTD9Xg2NWmMjp9x5 WKxEN7JXCtxy8ANTwgTUF9Bh0Q3gj35iCAP5vsXe91yJSJWLlkoR0IXpY bPiO+K6QUwX2HruK6DGVEHpZzc/9g2u2wPaqKySQq0dFnQ88wRF+7jOLF A==; X-CSE-ConnectionGUID: /2zkRH8USlmPA3KT8a3BHQ== X-CSE-MsgGUID: EFrfjNnPRoKJqb9UZuHMCg== X-IronPort-AV: E=McAfee;i="6700,10204,11246"; a="29901645" X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="29901645" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2024 14:36:43 -0800 X-CSE-ConnectionGUID: ZyEv4hC4S7Sr0zgUHYkTcg== X-CSE-MsgGUID: Kt6D4LmEScWsyZ4b2R4JDA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="83316976" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa006.fm.intel.com with ESMTP; 04 Nov 2024 14:36:43 -0800 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, netdev@vger.kernel.org Cc: Mateusz Polchlopek , anthony.l.nguyen@intel.com, Przemek Kitszel , Simon Horman , Pucha Himasekhar Reddy Subject: [PATCH net 2/6] ice: change q_index variable type to s16 to store -1 value Date: Mon, 4 Nov 2024 14:36:30 -0800 Message-ID: <20241104223639.2801097-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241104223639.2801097-1-anthony.l.nguyen@intel.com> References: <20241104223639.2801097-1-anthony.l.nguyen@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org From: Mateusz Polchlopek Fix Flow Director not allowing to re-map traffic to 0th queue when action is configured to drop (and vice versa). The current implementation of ethtool callback in the ice driver forbids change Flow Director action from 0 to -1 and from -1 to 0 with an error, e.g: # ethtool -U eth2 flow-type tcp4 src-ip 1.1.1.1 loc 1 action 0 # ethtool -U eth2 flow-type tcp4 src-ip 1.1.1.1 loc 1 action -1 rmgr: Cannot insert RX class rule: Invalid argument We set the value of `u16 q_index = 0` at the beginning of the function ice_set_fdir_input_set(). In case of "drop traffic" action (which is equal to -1 in ethtool) we store the 0 value. Later, when want to change traffic rule to redirect to queue with index 0 it returns an error caused by duplicate found. Fix this behaviour by change of the type of field `q_index` from u16 to s16 in `struct ice_fdir_fltr`. This allows to store -1 in the field in case of "drop traffic" action. What is more, change the variable type in the function ice_set_fdir_input_set() and assign at the beginning the new `#define ICE_FDIR_NO_QUEUE_IDX` which is -1. Later, if the action is set to another value (point specific queue index) the variable value is overwritten in the function. Fixes: cac2a27cd9ab ("ice: Support IPv4 Flow Director filters") Reviewed-by: Przemek Kitszel Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Reviewed-by: Hariprasad Kelam --- drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c | 3 ++- drivers/net/ethernet/intel/ice/ice_fdir.h | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c index 5412eff8ef23..ee9862ddfe15 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c @@ -1830,11 +1830,12 @@ static int ice_set_fdir_input_set(struct ice_vsi *vsi, struct ethtool_rx_flow_spec *fsp, struct ice_fdir_fltr *input) { - u16 dest_vsi, q_index = 0; + s16 q_index = ICE_FDIR_NO_QUEUE_IDX; u16 orig_q_index = 0; struct ice_pf *pf; struct ice_hw *hw; int flow_type; + u16 dest_vsi; u8 dest_ctl; if (!vsi || !fsp || !input) diff --git a/drivers/net/ethernet/intel/ice/ice_fdir.h b/drivers/net/ethernet/intel/ice/ice_fdir.h index ab5b118daa2d..820023c0271f 100644 --- a/drivers/net/ethernet/intel/ice/ice_fdir.h +++ b/drivers/net/ethernet/intel/ice/ice_fdir.h @@ -53,6 +53,8 @@ */ #define ICE_FDIR_IPV4_PKT_FLAG_MF 0x20 +#define ICE_FDIR_NO_QUEUE_IDX -1 + enum ice_fltr_prgm_desc_dest { ICE_FLTR_PRGM_DESC_DEST_DROP_PKT, ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QINDEX, @@ -186,7 +188,7 @@ struct ice_fdir_fltr { u16 flex_fltr; /* filter control */ - u16 q_index; + s16 q_index; u16 orig_q_index; u16 dest_vsi; u8 dest_ctl; From patchwork Mon Nov 4 22:36:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13862194 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 0DDD11FDF89; Mon, 4 Nov 2024 22:36:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759807; cv=none; b=kJDGpI96TaXXr/feaJaUA5/YY5jf8/SiJrj9ggWUB88Va8/4AOXOtqgpkh/AhUKksdt+BMCQvWp6hYlfsoKxFaXF77QLLXcsTLCxxvjpwCOR0D5RsfhHAmqBmLjqlQpSfdUAw+kAAeHpT5AMf+Lay7o5265zdlp3KIKFAz5HfQU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759807; c=relaxed/simple; bh=wTF9hP9guZdikKr/XQloHU6o8fSGUHG5LH9XHW0PRiU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RhkskSKLVXlSff02W5cKDL77KQ7VeJisHfIeMlWYAsF+gbM699aWuqgAcZCjj0eit3aiWrye80MNTIlqXPT8D6EXxLYw3weKF5ECEgGC59TMP8rG8KasNAA/D/5T+mKanTjo0YUDdmYpniXnb17ybUvogmW/tlxYrtIKg6yoWYw= 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=LJxTioP7; arc=none smtp.client-ip=192.198.163.19 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="LJxTioP7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730759806; x=1762295806; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=wTF9hP9guZdikKr/XQloHU6o8fSGUHG5LH9XHW0PRiU=; b=LJxTioP77r6P7hU9YlNIp04zh4QKigzqvmb1srpC94vN2zpQrosLn0WI L5gnEvyh4P/fBCWc/57NsuqkPvVl/BT9oI7VE+0mzZzBfO1rEsrAPAA5f fZ8HQwaY7O0IIE/M1R59dN3eahmmT0m3ayN33CKdj9Q2P/DSbW+3fofqx CqR9Jf17lbsD6dDtcuhoD1iZEDocAdH84xUkmeepnrLZebsVwlBfxF36h wKc2QuJ/KwwiEtZy9DZId698jI15qH4taTzY66vDKTqiqFh1GzuICbyGY nlQSW0OadbA6gCEqWPAPjj0rUKxb6MRzRKYAlJQnZUvHNCXhB+wzCF9YJ w==; X-CSE-ConnectionGUID: pwXaTmWMRDybdZhmDtqcvg== X-CSE-MsgGUID: ndvRD2/cSdKy48VWevdkWg== X-IronPort-AV: E=McAfee;i="6700,10204,11246"; a="29901651" X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="29901651" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2024 14:36:44 -0800 X-CSE-ConnectionGUID: AAfTJu8eTU+WJYsCkbfKWg== X-CSE-MsgGUID: 40CIxQkmTk+F5PRRk03E0g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="83316979" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa006.fm.intel.com with ESMTP; 04 Nov 2024 14:36:44 -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: Pavan Kumar Linga , anthony.l.nguyen@intel.com, stable@vger.kernel.org, horms@kernel.org, Tarun K Singh , Krishneil Singh Subject: [PATCH net 3/6] idpf: avoid vport access in idpf_get_link_ksettings Date: Mon, 4 Nov 2024 14:36:31 -0800 Message-ID: <20241104223639.2801097-4-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241104223639.2801097-1-anthony.l.nguyen@intel.com> References: <20241104223639.2801097-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: Pavan Kumar Linga When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps. Fixes: 02cbfba1add5 ("idpf: add ethtool callbacks") Cc: stable@vger.kernel.org # 6.7+ Reviewed-by: Tarun K Singh Signed-off-by: Pavan Kumar Linga Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf.h | 4 ++-- drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 11 +++-------- drivers/net/ethernet/intel/idpf/idpf_lib.c | 4 ++-- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 2 +- 4 files changed, 8 insertions(+), 13 deletions(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf.h b/drivers/net/ethernet/intel/idpf/idpf.h index 2c31ad87587a..66544faab710 100644 --- a/drivers/net/ethernet/intel/idpf/idpf.h +++ b/drivers/net/ethernet/intel/idpf/idpf.h @@ -141,6 +141,7 @@ enum idpf_vport_state { * @adapter: Adapter back pointer * @vport: Vport back pointer * @vport_id: Vport identifier + * @link_speed_mbps: Link speed in mbps * @vport_idx: Relative vport index * @state: See enum idpf_vport_state * @netstats: Packet and byte stats @@ -150,6 +151,7 @@ struct idpf_netdev_priv { struct idpf_adapter *adapter; struct idpf_vport *vport; u32 vport_id; + u32 link_speed_mbps; u16 vport_idx; enum idpf_vport_state state; struct rtnl_link_stats64 netstats; @@ -287,7 +289,6 @@ struct idpf_port_stats { * @tx_itr_profile: TX profiles for Dynamic Interrupt Moderation * @port_stats: per port csum, header split, and other offload stats * @link_up: True if link is up - * @link_speed_mbps: Link speed in mbps * @sw_marker_wq: workqueue for marker packets */ struct idpf_vport { @@ -331,7 +332,6 @@ struct idpf_vport { struct idpf_port_stats port_stats; bool link_up; - u32 link_speed_mbps; wait_queue_head_t sw_marker_wq; }; diff --git a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c index 3806ddd3ce4a..59b1a1a09996 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c +++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c @@ -1296,24 +1296,19 @@ static void idpf_set_msglevel(struct net_device *netdev, u32 data) static int idpf_get_link_ksettings(struct net_device *netdev, struct ethtool_link_ksettings *cmd) { - struct idpf_vport *vport; - - idpf_vport_ctrl_lock(netdev); - vport = idpf_netdev_to_vport(netdev); + struct idpf_netdev_priv *np = netdev_priv(netdev); ethtool_link_ksettings_zero_link_mode(cmd, supported); cmd->base.autoneg = AUTONEG_DISABLE; cmd->base.port = PORT_NONE; - if (vport->link_up) { + if (netif_carrier_ok(netdev)) { cmd->base.duplex = DUPLEX_FULL; - cmd->base.speed = vport->link_speed_mbps; + cmd->base.speed = np->link_speed_mbps; } else { cmd->base.duplex = DUPLEX_UNKNOWN; cmd->base.speed = SPEED_UNKNOWN; } - idpf_vport_ctrl_unlock(netdev); - return 0; } diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c index 4f20343e49a9..c3848e10e7db 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_lib.c +++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c @@ -1860,7 +1860,7 @@ int idpf_initiate_soft_reset(struct idpf_vport *vport, * mess with. Nothing below should use those variables from new_vport * and should instead always refer to them in vport if they need to. */ - memcpy(new_vport, vport, offsetof(struct idpf_vport, link_speed_mbps)); + memcpy(new_vport, vport, offsetof(struct idpf_vport, link_up)); /* Adjust resource parameters prior to reallocating resources */ switch (reset_cause) { @@ -1906,7 +1906,7 @@ int idpf_initiate_soft_reset(struct idpf_vport *vport, /* Same comment as above regarding avoiding copying the wait_queues and * mutexes applies here. We do not want to mess with those if possible. */ - memcpy(vport, new_vport, offsetof(struct idpf_vport, link_speed_mbps)); + memcpy(vport, new_vport, offsetof(struct idpf_vport, link_up)); if (reset_cause == IDPF_SR_Q_CHANGE) idpf_vport_alloc_vec_indexes(vport); diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index 15c00a01f1c0..ce217e274506 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c @@ -141,7 +141,7 @@ static void idpf_handle_event_link(struct idpf_adapter *adapter, } np = netdev_priv(vport->netdev); - vport->link_speed_mbps = le32_to_cpu(v2e->link_speed); + np->link_speed_mbps = le32_to_cpu(v2e->link_speed); if (vport->link_up == v2e->link_status) return; From patchwork Mon Nov 4 22:36:32 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13862195 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 D4F4A1FDFAC; Mon, 4 Nov 2024 22:36:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759808; cv=none; b=HCeb6o7fqFi0LOPAX3/TQZKHKiT6H4zNv7s6mYZ+A+sCzl7nNH5ZL93LeHejGLXhri3ygOSabP6UOBa2iMqnvn7N2TRMUJEnAakdwvJqxsMNgHsGORBPjQp4xT9iVDVdT7NsPx4olawXiUpOTxoZ+CZMJQScJxqlnUJRb1LnhUQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759808; c=relaxed/simple; bh=s25n+lGXySaaa5BNfdNG6reGej0xd8Kh1yklFjZEAaI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tyV+Us7bfj0vN5VEUxIYOL/0eVbwoC7a2UUMNauxbJEayVXYJkgLMDfRIZQF6Jyto8enaQfFZ4TAhZtGEK+wOe9U2axEMQxy1Kg6Eo7cQqpGyTf1fPDfEHkFXFCkZuPJDUHKld48sRYjjuhmWRE9CK2y4x77VEbVPrhDOJ2dyw4= 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=h1iFxLiX; arc=none smtp.client-ip=192.198.163.19 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="h1iFxLiX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730759807; x=1762295807; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=s25n+lGXySaaa5BNfdNG6reGej0xd8Kh1yklFjZEAaI=; b=h1iFxLiX0PK1FIpLrTVDOtn180+xgCdZFiqEyjxxErmERP04pWHLtuo5 4ycY6RUhcKdLDNdddfBY/bJux2RiqJf8v+qw0YBafsFJB2j8blQOCGrbG s6jmqfvynrHreR4bAk9SH7RJoqB6khCX2QDGEiBlntW3wK1wpnjgdgnF8 1G5ebgTEiviF/s7JhLZI8rlr/KACc3OJkwP/rfYOb7WWI88W8uN28Jv2a 6YFmG25Yz/0tA7Tr20ERqR3NOd616w8Fpq7dl/ILeDWWKMk0QIF9v8Hv4 K/vIcMOVZ4QG4psxlZxD9JhnwUPQbYWtQ3OiXD8LXW8cwAjhXKKDqBUax w==; X-CSE-ConnectionGUID: lD3no64SRg2afAnk9wTtRg== X-CSE-MsgGUID: xkyg9h7mQE2Wc/rCo7smfw== X-IronPort-AV: E=McAfee;i="6700,10204,11246"; a="29901657" X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="29901657" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2024 14:36:44 -0800 X-CSE-ConnectionGUID: Bo7c++GbRVanT2tiItashg== X-CSE-MsgGUID: KeTma+axRRKBV2sP6pVO0A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="83316982" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa006.fm.intel.com with ESMTP; 04 Nov 2024 14:36:44 -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: Pavan Kumar Linga , anthony.l.nguyen@intel.com, stable@vger.kernel.org, horms@kernel.org, Tarun K Singh , Krishneil Singh Subject: [PATCH net 4/6] idpf: fix idpf_vc_core_init error path Date: Mon, 4 Nov 2024 14:36:32 -0800 Message-ID: <20241104223639.2801097-5-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241104223639.2801097-1-anthony.l.nguyen@intel.com> References: <20241104223639.2801097-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: Pavan Kumar Linga In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized. Fixes: 4930fbf419a7 ("idpf: add core init and interrupt request") Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Cc: stable@vger.kernel.org # 6.9+ Reviewed-by: Tarun K Singh Signed-off-by: Pavan Kumar Linga Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/idpf/idpf_lib.c | 1 + drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c index c3848e10e7db..b4fbb99bfad2 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_lib.c +++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c @@ -1786,6 +1786,7 @@ static int idpf_init_hard_reset(struct idpf_adapter *adapter) */ err = idpf_vc_core_init(adapter); if (err) { + cancel_delayed_work_sync(&adapter->mbx_task); idpf_deinit_dflt_mbx(adapter); goto unlock_mutex; } diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index ce217e274506..d46c95f91b0d 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c @@ -3063,7 +3063,6 @@ int idpf_vc_core_init(struct idpf_adapter *adapter) adapter->state = __IDPF_VER_CHECK; if (adapter->vcxn_mngr) idpf_vc_xn_shutdown(adapter->vcxn_mngr); - idpf_deinit_dflt_mbx(adapter); set_bit(IDPF_HR_DRV_LOAD, adapter->flags); queue_delayed_work(adapter->vc_event_wq, &adapter->vc_event_task, msecs_to_jiffies(task_delay)); From patchwork Mon Nov 4 22:36:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13862197 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 4DBA11FDFBD for ; Mon, 4 Nov 2024 22:36:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759809; cv=none; b=K5HVAu/agTVPKiBz1OiD0kAmmam7OO5nbIWLK9+Sk754fWM8lNcI8TUwlEA3uoAxSiya/t3633eF6NhnMEXgSc7YPWA2nnxpDSeUczX0ZS9KRpuSXHlSoKCCEA8h4nhL8pWdZ50GMz31y4FplGtgGoOrkWInwVzti8A7LeBsEqc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759809; c=relaxed/simple; bh=PakvhkEE6JEvuCwa4DDvrWq7PrbhGi7gRwSzf85AW18=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mBt67WKgb+ob0ccebYnOaPatMJuW8Egk0quKsBEI1rwWrMw0kNA6SU4/7BBkwA+M8QNi9fjCZ5dP3KQ3GRylIu8PCN09UQNZG2yN2FZ15rvP+4OtRWinnFhBmf65Ad3RdN37M4TfOE6N2DRT1DpHFHKeEyCMiYlaDA/UDqBgVdk= 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=CZMA1fTn; arc=none smtp.client-ip=192.198.163.19 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="CZMA1fTn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730759807; x=1762295807; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=PakvhkEE6JEvuCwa4DDvrWq7PrbhGi7gRwSzf85AW18=; b=CZMA1fTnApMcbW3jidaYRW1zYTZTbi+7PoL33rkxF7C2Olp5QPdmZNCU HaKEvlnWGNez++axnT9IzFobXgnTJfnGcwL7oiJwNKXCClgVY7SRxtNd8 zWybBT5o+0qdUguj77DoACWsYusOem4bLyf9Jx/lTePbnYJoUcstOTb+B gMVY0TWm4xp1s73ojIM8AyR5dZ51kFjZ/C0aKMF7QOOsqwO9fvOLQNMVZ NKAtZoqQ65mdocDJConmY4Z4y4HWdXFokKBz/G1avK8o9EAOJq91tIAW+ mMOc/4nsPZr3cNlncX8jS4npx+Q+7wJLXLTbq0gG7+iNck4aRqdgItbf7 Q==; X-CSE-ConnectionGUID: 1No4192fSHGouqnpXRU/WA== X-CSE-MsgGUID: /giTx7luRXC7Q1/5JVNF1A== X-IronPort-AV: E=McAfee;i="6700,10204,11246"; a="29901663" X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="29901663" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2024 14:36:45 -0800 X-CSE-ConnectionGUID: pGxhx5McSAqjGjp17WA97w== X-CSE-MsgGUID: B5i9R5ZYQpmfu5R5the9/A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="83316985" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa006.fm.intel.com with ESMTP; 04 Nov 2024 14:36:44 -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: Aleksandr Loktionov , anthony.l.nguyen@intel.com, Pucha Himasekhar Reddy , Michal Schmidt Subject: [PATCH net 5/6] i40e: fix race condition by adding filter's intermediate sync state Date: Mon, 4 Nov 2024 14:36:33 -0800 Message-ID: <20241104223639.2801097-6-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241104223639.2801097-1-anthony.l.nguyen@intel.com> References: <20241104223639.2801097-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: Aleksandr Loktionov Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: "Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process. Fixes: 278e7d0b9d68 ("i40e: store MAC/VLAN filters in a hash with the MAC Address as key") Signed-off-by: Aleksandr Loktionov Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Reviewed-by: Michal Schmidt Tested-by: Michal Schmidt Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/i40e/i40e.h | 1 + drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 1 + drivers/net/ethernet/intel/i40e/i40e_main.c | 12 ++++++++++-- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h index 2089a0e172bf..d4255c2706fa 100644 --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -755,6 +755,7 @@ enum i40e_filter_state { I40E_FILTER_ACTIVE, /* Added to switch by FW */ I40E_FILTER_FAILED, /* Rejected by FW */ I40E_FILTER_REMOVE, /* To be removed */ + I40E_FILTER_NEW_SYNC, /* New, not sent yet, is in i40e_sync_vsi_filters() */ /* There is no 'removed' state; the filter struct is freed */ }; struct i40e_mac_filter { diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c index abf624d770e6..208c2f0857b6 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c @@ -89,6 +89,7 @@ static char *i40e_filter_state_string[] = { "ACTIVE", "FAILED", "REMOVE", + "NEW_SYNC", }; /** diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 25295ae370b2..55fb362eb508 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -1255,6 +1255,7 @@ int i40e_count_filters(struct i40e_vsi *vsi) hash_for_each_safe(vsi->mac_filter_hash, bkt, h, f, hlist) { if (f->state == I40E_FILTER_NEW || + f->state == I40E_FILTER_NEW_SYNC || f->state == I40E_FILTER_ACTIVE) ++cnt; } @@ -1441,6 +1442,8 @@ static int i40e_correct_mac_vlan_filters(struct i40e_vsi *vsi, new->f = add_head; new->state = add_head->state; + if (add_head->state == I40E_FILTER_NEW) + add_head->state = I40E_FILTER_NEW_SYNC; /* Add the new filter to the tmp list */ hlist_add_head(&new->hlist, tmp_add_list); @@ -1550,6 +1553,8 @@ static int i40e_correct_vf_mac_vlan_filters(struct i40e_vsi *vsi, return -ENOMEM; new_mac->f = add_head; new_mac->state = add_head->state; + if (add_head->state == I40E_FILTER_NEW) + add_head->state = I40E_FILTER_NEW_SYNC; /* Add the new filter to the tmp list */ hlist_add_head(&new_mac->hlist, tmp_add_list); @@ -2437,7 +2442,8 @@ static int i40e_aqc_broadcast_filter(struct i40e_vsi *vsi, const char *vsi_name, struct i40e_mac_filter *f) { - bool enable = f->state == I40E_FILTER_NEW; + bool enable = f->state == I40E_FILTER_NEW || + f->state == I40E_FILTER_NEW_SYNC; struct i40e_hw *hw = &vsi->back->hw; int aq_ret; @@ -2611,6 +2617,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi) /* Add it to the hash list */ hlist_add_head(&new->hlist, &tmp_add_list); + f->state = I40E_FILTER_NEW_SYNC; } /* Count the number of active (current and new) VLAN @@ -2762,7 +2769,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi) spin_lock_bh(&vsi->mac_filter_hash_lock); hlist_for_each_entry_safe(new, h, &tmp_add_list, hlist) { /* Only update the state if we're still NEW */ - if (new->f->state == I40E_FILTER_NEW) + if (new->f->state == I40E_FILTER_NEW || + new->f->state == I40E_FILTER_NEW_SYNC) new->f->state = new->state; hlist_del(&new->hlist); netdev_hw_addr_refcnt(new->f, vsi->netdev, -1); From patchwork Mon Nov 4 22:36:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13862196 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 CBBFF1FE0ED for ; Mon, 4 Nov 2024 22:36:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759809; cv=none; b=slU5rEVH+HCG+w7VPFZiUHcMuc7KCFTb8HmKYTb3ezl9SZeykczlXIFqVWcyWnQEksPycfhbNL8P+8fwxxbhjOsxiXvP/9LcXkXeXM0xr0/t41UOqwZ71kkwbM9uijHN50I1woHdkv/+U0thDijE8mvoZyXREC51inIAyXTsNKo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730759809; c=relaxed/simple; bh=EiKJf1+KTD45R2F3QILUk43HCVQm6LiEQvLOq8hnLTk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ag6TFXH30dwLO+j6YMMXFMjrDWkTpVHRaipfiDPpginwF305PStMVIKnqmRMk8hW8UhFlIO/aJnvnKxBus9uK/4p/d5j/HBUSuH1iInBcdDECFBURDuyJBLXZNxhHeONX1yXeLhBxVfLG3ik/docDM26Tb8pjdWHK0KvnuBu/bU= 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=lqzZua8G; arc=none smtp.client-ip=192.198.163.19 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="lqzZua8G" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730759807; x=1762295807; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=EiKJf1+KTD45R2F3QILUk43HCVQm6LiEQvLOq8hnLTk=; b=lqzZua8GXEWs3gBRozRzdJMtRjzf2POAhB6gs8E3M3dhDyg2NPsWIZbK Tnce1wcup00BuYMQhmGCa4nsVZz/ZukU2W4D4KB1OVkPVjBOREiT+njlu /Jcz9flt6Yi3x372yy5Pouu0UIUOztj/0z6ygsFqWlZVY9civIpgRvxFW ptBe9qpGNoPdmil/dSbjAPN1FXY5rdkm3/d8VIvPfvUlVSsi777m2XX1d 9A781tumFHXTfj2mKFyRYluDeRr67j0HireyOnkK736U56Rsxu7KjBulB jR+tIN0650wGqQeb8NJW1LJSLiKsygSd4uywYBXkPfKCNtphSIhTc3ZsC g==; X-CSE-ConnectionGUID: ku/adgSwSHCx55oBQjiiIw== X-CSE-MsgGUID: 65DavpZ9StWn1LlUKwcGxw== X-IronPort-AV: E=McAfee;i="6700,10204,11246"; a="29901669" X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="29901669" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2024 14:36:45 -0800 X-CSE-ConnectionGUID: I3zQZecoTqGYujXdghq0jA== X-CSE-MsgGUID: LThFhj4gSoGPZIlXFrhO5A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,258,1725346800"; d="scan'208";a="83316988" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa006.fm.intel.com with ESMTP; 04 Nov 2024 14:36:45 -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: Vitaly Lifshits , anthony.l.nguyen@intel.com, dima.ruinskiy@intel.com, horms@kernel.org, Avigail Dahan Subject: [PATCH net 6/6] e1000e: Remove Meteor Lake SMBUS workarounds Date: Mon, 4 Nov 2024 14:36:34 -0800 Message-ID: <20241104223639.2801097-7-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241104223639.2801097-1-anthony.l.nguyen@intel.com> References: <20241104223639.2801097-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: Vitaly Lifshits This is a partial revert to commit 76a0a3f9cc2f ("e1000e: fix force smbus during suspend flow"). That commit fixed a sporadic PHY access issue but introduced a regression in runtime suspend flows. The original issue on Meteor Lake systems was rare in terms of the reproduction rate and the number of the systems affected. After the integration of commit 0a6ad4d9e169 ("e1000e: avoid failing the system during pm_suspend"), PHY access loss can no longer cause a system-level suspend failure. As it only occurs when the LAN cable is disconnected, and is recovered during system resume flow. Therefore, its functional impact is low, and the priority is given to stabilizing runtime suspend. Fixes: 76a0a3f9cc2f ("e1000e: fix force smbus during suspend flow") Signed-off-by: Vitaly Lifshits Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/e1000e/ich8lan.c | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c index ce227b56cf72..2f9655cf5dd9 100644 --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c @@ -1205,12 +1205,10 @@ s32 e1000_enable_ulp_lpt_lp(struct e1000_hw *hw, bool to_sx) if (ret_val) goto out; - if (hw->mac.type != e1000_pch_mtp) { - ret_val = e1000e_force_smbus(hw); - if (ret_val) { - e_dbg("Failed to force SMBUS: %d\n", ret_val); - goto release; - } + ret_val = e1000e_force_smbus(hw); + if (ret_val) { + e_dbg("Failed to force SMBUS: %d\n", ret_val); + goto release; } /* Si workaround for ULP entry flow on i127/rev6 h/w. Enable @@ -1273,13 +1271,6 @@ s32 e1000_enable_ulp_lpt_lp(struct e1000_hw *hw, bool to_sx) } release: - if (hw->mac.type == e1000_pch_mtp) { - ret_val = e1000e_force_smbus(hw); - if (ret_val) - e_dbg("Failed to force SMBUS over MTL system: %d\n", - ret_val); - } - hw->phy.ops.release(hw); out: if (ret_val)