From patchwork Tue Oct 8 23:00:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13827176 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 5858721265D for ; Tue, 8 Oct 2024 23:01:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428472; cv=none; b=OpeL21AhknLuyQ88dZsfNd6esGTOkv0DyMuYr9j/YQR2KnhUhbpzWgB/AF9WEw7JKWDomTc8zzPVmrNd1s653YyBh4LqJLAmG/urSV71c4WNvTjGhUc+vzRet0vQY6D0dmyheBimx0rjENbE2lJM2aenl8WQ3bZ2Rvb5aJphQIo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428472; c=relaxed/simple; bh=MxJXCxTKXAjqP+xHbBRY5zuTrUgWf7qq2Y7UuuWGOS0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KZWd3euNuCDuNB3wU/zLgSgbqcKdE4cVjFtJYGsoshXmE4xhmDPaAfvn4EE2WfSVOUY5s5L27nH3QGbuztMC96uO4Sit3V+AVIWr2RF5QCM5KdVZDfqlB8DouryuP7jrhaDlc4FWjeCUg2MIk31k8Kmpo14GZ7264wh7Y3+/Gps= 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=QR5KKoNH; arc=none smtp.client-ip=192.198.163.16 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="QR5KKoNH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728428471; x=1759964471; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=MxJXCxTKXAjqP+xHbBRY5zuTrUgWf7qq2Y7UuuWGOS0=; b=QR5KKoNH4JkflMAz5ix3vnSMddQNM3IBY0pqjRB5rzN5nrnyVmOyStA4 kJ5uE0IMGTMYDl/WImXMV/oI6RPZ0rZDauWPqvbwyTQBsbVvEssPIyba1 ZPcnmchTVKQGrU6FyR3CS8Wf6eWepnHIDutVBrMXekI3mjKKdnkoNBBn8 eg3t4lfY6dGQrNzDlm5i1U/RG5fv5Y9+6PGbZDgzLGqI5+Zh6ZU4JotOK VXVFnoX4eOHoUmw0oRzRCfUq0u3own4aWS4uj3f0i22tohcwc672oriIy S/bgoG+4NHaCqh+3TkiekGPyv5g1/mitSWH4q5k6HF4QkoLV+6VA82knI w==; X-CSE-ConnectionGUID: hkG/Kru0SCyYUvAm1LMx5Q== X-CSE-MsgGUID: L4w/30nyQOm37zuAMbZQog== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="15302402" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="15302402" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 16:01:09 -0700 X-CSE-ConnectionGUID: IQgS+pKwSgywb25C3UVHuQ== X-CSE-MsgGUID: YkbO4pVIRy657bO8SEqoIg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="106787572" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa001.fm.intel.com with ESMTP; 08 Oct 2024 16:01:03 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Marcin Szycik , anthony.l.nguyen@intel.com, mateusz.polchlopek@intel.com, maciej.fijalkowski@intel.com, Przemek Kitszel , Brett Creeley , Pucha Himasekhar Reddy Subject: [PATCH net 1/7] ice: Fix entering Safe Mode Date: Tue, 8 Oct 2024 16:00:39 -0700 Message-ID: <20241008230050.928245-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241008230050.928245-1-anthony.l.nguyen@intel.com> References: <20241008230050.928245-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 If DDP package is missing or corrupted, the driver should enter Safe Mode. Instead, an error is returned and probe fails. To fix this, don't exit init if ice_init_ddp_config() returns an error. Repro: * Remove or rename DDP package (/lib/firmware/intel/ice/ddp/ice.pkg) * Load ice Fixes: cc5776fe1832 ("ice: Enable switching default Tx scheduler topology") Reviewed-by: Przemek Kitszel Signed-off-by: Marcin Szycik Reviewed-by: Brett Creeley Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Reviewed-by: Maciej Fijalkowski --- drivers/net/ethernet/intel/ice/ice_main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index fbab72fab79c..da1352dc26af 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -4767,14 +4767,12 @@ int ice_init_dev(struct ice_pf *pf) ice_init_feature_support(pf); err = ice_init_ddp_config(hw, pf); - if (err) - return err; /* if ice_init_ddp_config fails, ICE_FLAG_ADV_FEATURES bit won't be * set in pf->state, which will cause ice_is_safe_mode to return * true */ - if (ice_is_safe_mode(pf)) { + if (err || ice_is_safe_mode(pf)) { /* we already got function/device capabilities but these don't * reflect what the driver needs to do in safe mode. Instead of * adding conditional logic everywhere to ignore these From patchwork Tue Oct 8 23:00:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13827175 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 84904215011 for ; Tue, 8 Oct 2024 23:01:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428472; cv=none; b=IDZQJxy+pXbEQwoBV2bO6iPM0g4BSoIqUsyO75nw/fPL7gIAZYDrHuSt4caeSpdqM9iSmoNplRJNe85rHM9QkIy0LAlCJJWEvnaPVKM0o+jNvvrscRRDwN8yASOQGGcn2Mwf6KXi90C6pnKm6+J2QMC4X+0bI4W5ZbHHsIPhhE8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428472; c=relaxed/simple; bh=3dQ4XjTRMsfnlV6ZByugi51po1JJk35AH9+e8ooljc4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nPaqVZcVb/6sU6eYIOhBZv4rGKAxqnDT1jYGz8qahzB8Bil8kntpAFF5n0MBu2dj4/9ljbQ/cN7Rry94qvqt9aTi6W9dA1GMlQC/ftybfzl9E469zlnz7R1oaJB/TM8TrM77TZbuA4LzOK8uu5bztFLNd9DdnKUi3SZqgfnn14w= 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=I5zqvW0T; arc=none smtp.client-ip=192.198.163.16 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="I5zqvW0T" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728428471; x=1759964471; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=3dQ4XjTRMsfnlV6ZByugi51po1JJk35AH9+e8ooljc4=; b=I5zqvW0TrEryKq4GPC/pLfNDz9BqDXHkZ+wilqxeqAva9VYs5LtggD3G 8W2rnt9sUiGErpc8wI7NuVs9dOOsAecWaUwA6ofC874MIdeSKlCvWXvwi 5gY6L2JCIFh5b9NTLuHCPVdnCxGEecwjn5uV7vbN6ltavoQ+HeQ9Fx2oo rJjQYmUdwcVD6Dwa6m4gt88vW+OW09GuCg+PF1I2OWnz0pza0Wrnwqxz5 f9HCEsJthDKQYqsfERhLl1kmboleiwu1gR1pUhhu7EFWDbkMxkg9Woq3l u+xTtC4wtTdBlsB1B2uD02DOwCdM8imuNcHeks7DQi9AQTnJTsZ+RwtTC Q==; X-CSE-ConnectionGUID: aYmWnye/QCajENvcYSfhkQ== X-CSE-MsgGUID: fleB0wXuQ+yiYRqGVzdyUg== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="15302395" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="15302395" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 16:01:09 -0700 X-CSE-ConnectionGUID: IpnLi+VkRWKSP474LlmU3Q== X-CSE-MsgGUID: nZavYsCmSYGMENqOQ0gpoQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="106787577" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa001.fm.intel.com with ESMTP; 08 Oct 2024 16:01:04 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Marcin Szycik , anthony.l.nguyen@intel.com, mateusz.polchlopek@intel.com, maciej.fijalkowski@intel.com, Przemek Kitszel , Brett Creeley , Sujai Buvaneswaran Subject: [PATCH net 2/7] ice: Fix netif_is_ice() in Safe Mode Date: Tue, 8 Oct 2024 16:00:40 -0700 Message-ID: <20241008230050.928245-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241008230050.928245-1-anthony.l.nguyen@intel.com> References: <20241008230050.928245-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 netif_is_ice() works by checking the pointer to netdev ops. However, it only checks for the default ice_netdev_ops, not ice_netdev_safe_mode_ops, so in Safe Mode it always returns false, which is unintuitive. While it doesn't look like netif_is_ice() is currently being called anywhere in Safe Mode, this could change and potentially lead to unexpected behaviour. Fixes: df006dd4b1dc ("ice: Add initial support framework for LAG") Reviewed-by: Przemek Kitszel Signed-off-by: Marcin Szycik Reviewed-by: Brett Creeley Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index da1352dc26af..09d1a4eb5716 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -87,7 +87,8 @@ ice_indr_setup_tc_cb(struct net_device *netdev, struct Qdisc *sch, bool netif_is_ice(const struct net_device *dev) { - return dev && (dev->netdev_ops == &ice_netdev_ops); + return dev && (dev->netdev_ops == &ice_netdev_ops || + dev->netdev_ops == &ice_netdev_safe_mode_ops); } /** From patchwork Tue Oct 8 23:00:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13827177 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 A7780215F5A for ; Tue, 8 Oct 2024 23:01:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428473; cv=none; b=LtkTiSpZ3Ox89tnT2hFrZUPpiX9gGJu4CAiHpSd8DLRIzNmUS7LrCd2KWlnWdQ5+7uqSFNKgF6MfrKZbIOOitccOXKRr9HqD/tc6EHr2trBc4ob/+nRIiGEqntML4PsNaDTePkkQ1qCYgIze3ZwvHnU04rj23Co2qJg/0quyztY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428473; c=relaxed/simple; bh=LF8uBmxrYp5MpdiB1kxsi1hPL2B9zDj76UHT6rM1LAc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CRVg5lYhBq7isuG/BVrdDOhML43HpZ8NqapNkI6O3L38Qn4LUbHMk4vl0Rc4a7dfFYAG66l3jAMxZiDmpGxLJ58I0mZIY0XGIUv3OmNTmRu8rUHRgEvrl+SD+ACTlQdnwJ+2ZDJ0fesVKSs9gaJV0+e3yill01X5gZBAf4iWGWE= 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=UnQf5gAa; arc=none smtp.client-ip=192.198.163.16 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="UnQf5gAa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728428472; x=1759964472; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=LF8uBmxrYp5MpdiB1kxsi1hPL2B9zDj76UHT6rM1LAc=; b=UnQf5gAaoLWosmWT+NyyGd1cEy+yjp7ys3m1GSH/TC6c+fKLZRRHM8+s iQk3FVXVm5zQuWM5OanmuRrtExGNCabaVZ291TI0v4RzhYXVHVN5Bgl2T IB6yMOi4Y3ms53pupJ1iMDRwuBkAg6eIt8RNcxUuVngZqHlPSJomALd1R Hc3Qy3grFS3jVb+3Y5ZmVFZluOaGtmdB0oN/IVud/LUEhcHU8FNMifYyl IWTpvL6TIedt0/EZd9TUN0oK872nUVNDO7tDIlC31mIDKqqu4NUHvv13h onRq1S1fdgCP2UfXmex4MGFGl3K3MoLc3viwsCfBSIplKHO420lEPmxlV g==; X-CSE-ConnectionGUID: iZ96XN44Tf2h4dK9iNoOXw== X-CSE-MsgGUID: gaV0eye1RemCQFth5c/d9A== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="15302409" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="15302409" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 16:01:10 -0700 X-CSE-ConnectionGUID: AkQCb1B/QdWBk6pUHfrv+Q== X-CSE-MsgGUID: rYy1U8D2Thym7cTEwTM1zw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="106787585" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa001.fm.intel.com with ESMTP; 08 Oct 2024 16:01:04 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Wojciech Drewek , anthony.l.nguyen@intel.com, horms@kernel.org, michal.swiatkowski@linux.intel.com, Mateusz Polchlopek , Sujai Buvaneswaran Subject: [PATCH net 3/7] ice: Flush FDB entries before reset Date: Tue, 8 Oct 2024 16:00:41 -0700 Message-ID: <20241008230050.928245-4-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241008230050.928245-1-anthony.l.nguyen@intel.com> References: <20241008230050.928245-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: Wojciech Drewek Triggering the reset while in switchdev mode causes errors[1]. Rules are already removed by this time because switch content is flushed in case of the reset. This means that rules were deleted from HW but SW still thinks they exist so when we get SWITCHDEV_FDB_DEL_TO_DEVICE notification we try to delete not existing rule. We can avoid these errors by clearing the rules early in the reset flow before they are removed from HW. Switchdev API will get notified that the rule was removed so we won't get SWITCHDEV_FDB_DEL_TO_DEVICE notification. Remove unnecessary ice_clear_sw_switch_recipes. [1] ice 0000:01:00.0: Failed to delete FDB forward rule, err: -2 ice 0000:01:00.0: Failed to delete FDB guard rule, err: -2 Fixes: 7c945a1a8e5f ("ice: Switchdev FDB events support") Reviewed-by: Mateusz Polchlopek Signed-off-by: Wojciech Drewek Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen --- .../net/ethernet/intel/ice/ice_eswitch_br.c | 5 +++- .../net/ethernet/intel/ice/ice_eswitch_br.h | 1 + drivers/net/ethernet/intel/ice/ice_main.c | 24 +++---------------- 3 files changed, 8 insertions(+), 22 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch_br.c b/drivers/net/ethernet/intel/ice/ice_eswitch_br.c index f5aceb32bf4d..cccb7ddf61c9 100644 --- a/drivers/net/ethernet/intel/ice/ice_eswitch_br.c +++ b/drivers/net/ethernet/intel/ice/ice_eswitch_br.c @@ -582,10 +582,13 @@ ice_eswitch_br_switchdev_event(struct notifier_block *nb, return NOTIFY_DONE; } -static void ice_eswitch_br_fdb_flush(struct ice_esw_br *bridge) +void ice_eswitch_br_fdb_flush(struct ice_esw_br *bridge) { struct ice_esw_br_fdb_entry *entry, *tmp; + if (!bridge) + return; + list_for_each_entry_safe(entry, tmp, &bridge->fdb_list, list) ice_eswitch_br_fdb_entry_notify_and_cleanup(bridge, entry); } diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch_br.h b/drivers/net/ethernet/intel/ice/ice_eswitch_br.h index c15c7344d7f8..66a2c804338f 100644 --- a/drivers/net/ethernet/intel/ice/ice_eswitch_br.h +++ b/drivers/net/ethernet/intel/ice/ice_eswitch_br.h @@ -117,5 +117,6 @@ void ice_eswitch_br_offloads_deinit(struct ice_pf *pf); int ice_eswitch_br_offloads_init(struct ice_pf *pf); +void ice_eswitch_br_fdb_flush(struct ice_esw_br *bridge); #endif /* _ICE_ESWITCH_BR_H_ */ diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index 09d1a4eb5716..b1e7727b8677 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -521,25 +521,6 @@ static void ice_pf_dis_all_vsi(struct ice_pf *pf, bool locked) pf->vf_agg_node[node].num_vsis = 0; } -/** - * ice_clear_sw_switch_recipes - clear switch recipes - * @pf: board private structure - * - * Mark switch recipes as not created in sw structures. There are cases where - * rules (especially advanced rules) need to be restored, either re-read from - * hardware or added again. For example after the reset. 'recp_created' flag - * prevents from doing that and need to be cleared upfront. - */ -static void ice_clear_sw_switch_recipes(struct ice_pf *pf) -{ - struct ice_sw_recipe *recp; - u8 i; - - recp = pf->hw.switch_info->recp_list; - for (i = 0; i < ICE_MAX_NUM_RECIPES; i++) - recp[i].recp_created = false; -} - /** * ice_prepare_for_reset - prep for reset * @pf: board private structure @@ -576,8 +557,9 @@ ice_prepare_for_reset(struct ice_pf *pf, enum ice_reset_req reset_type) mutex_unlock(&pf->vfs.table_lock); if (ice_is_eswitch_mode_switchdev(pf)) { - if (reset_type != ICE_RESET_PFR) - ice_clear_sw_switch_recipes(pf); + rtnl_lock(); + ice_eswitch_br_fdb_flush(pf->eswitch.br_offloads->bridge); + rtnl_unlock(); } /* release ADQ specific HW and SW resources */ From patchwork Tue Oct 8 23:00:42 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13827178 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 93D98216A21 for ; Tue, 8 Oct 2024 23:01:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428474; cv=none; b=JdJNsuXsXsUC/+hzutH+XQbDFMCcibobv5sJLEqhjWm7dCvhnucrQeiput/eITKfIbQTwCgTVY9fZvOXJUzeeX5kkHRC5543X+jn7GmrZ+hpgd4KAto7aQqbRDH8LW+sFS79+bhJUBDmLyPzpDAvWxXIt7EhQoRig2SPzTJBilg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428474; c=relaxed/simple; bh=7XyXJqfiNF825SX/6My4tvB2y9vPZ/Jp9eeDzkQVYw4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TZ/tfb+8ihU9sqtDZoafUmUpiMpPeIgoVkJjL577TjX6mpEmRF/t+bAhDiCrKGOFrDlsio4njpzRzYC6JJyQESvOapdxKPaOvJZkqZpOPn1e/ty/tvUnXAv4ka1OsYhBUyfFNXQ3qZ1ttHxyKBVZBpDx/2z4p1kRFvxDZRB63jw= 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=Ed2c+II0; arc=none smtp.client-ip=192.198.163.16 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="Ed2c+II0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728428473; x=1759964473; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=7XyXJqfiNF825SX/6My4tvB2y9vPZ/Jp9eeDzkQVYw4=; b=Ed2c+II06HqPAFKDi8At4kbx9C3uO7AS0Dd0o+Rn4RAqaX1UrA2SJrDa bcRf+8UtaQ0T+U1bpmeahhGnAGWyHSQxUxo7msrrAGt83FiIuEUXoECy4 ydnYrYYiu7ivH6x7h+fRY93gfPn23DQQGuo/BiCA8/G9l31jSxhzc/PWN b3FzYCVkOEzYsC3QFCU6abo/68znYQzH7xqzov8jqMow6NQttsKbfwrmJ 52djM8gyKke9HLMLYndqfY+ky9Rf2VN0UauVR3d0AMdb7UWUyNdLEFLrx HJM5r7Z+IS1KUN08OMoW41931OewI9LYaEOIVA5QcYB4IFrXZWUi3T+2O A==; X-CSE-ConnectionGUID: 7IXxCK0hReKPDHsrEy3Yiw== X-CSE-MsgGUID: v2p3Vk2bQ0yy5FnPubya8Q== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="15302417" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="15302417" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 16:01:10 -0700 X-CSE-ConnectionGUID: DJRu0z05QhW9ZB8r+SDT0g== X-CSE-MsgGUID: 0emo9FP/RgS1NtdQX3eygg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="106787592" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa001.fm.intel.com with ESMTP; 08 Oct 2024 16:01:04 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Marcin Szycik , anthony.l.nguyen@intel.com, poros@redhat.com, jacob.e.keller@intel.com, przemyslaw.kitszel@intel.com, Michal Swiatkowski , Simon Horman , Rafal Romanowski Subject: [PATCH net 4/7] ice: Fix increasing MSI-X on VF Date: Tue, 8 Oct 2024 16:00:42 -0700 Message-ID: <20241008230050.928245-5-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241008230050.928245-1-anthony.l.nguyen@intel.com> References: <20241008230050.928245-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 Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary. Reported-by: Jacob Keller Fixes: 2a2cb4c6c181 ("ice: replace ice_vf_recreate_vsi() with ice_vf_reconfig_vsi()") Reviewed-by: Michal Swiatkowski Signed-off-by: Marcin Szycik Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_sriov.c | 11 ++++++++--- drivers/net/ethernet/intel/ice/ice_vf_lib.c | 2 +- drivers/net/ethernet/intel/ice/ice_vf_lib_private.h | 1 - 3 files changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c index c2d6b2a144e9..91cb393f616f 100644 --- a/drivers/net/ethernet/intel/ice/ice_sriov.c +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c @@ -1121,7 +1121,10 @@ int ice_sriov_set_msix_vec_count(struct pci_dev *vf_dev, int msix_vec_count) if (vf->first_vector_idx < 0) goto unroll; - if (ice_vf_reconfig_vsi(vf) || ice_vf_init_host_cfg(vf, vsi)) { + vsi->req_txq = queues; + vsi->req_rxq = queues; + + if (ice_vsi_rebuild(vsi, ICE_VSI_FLAG_NO_INIT)) { /* Try to rebuild with previous values */ needs_rebuild = true; goto unroll; @@ -1150,8 +1153,10 @@ int ice_sriov_set_msix_vec_count(struct pci_dev *vf_dev, int msix_vec_count) } if (needs_rebuild) { - ice_vf_reconfig_vsi(vf); - ice_vf_init_host_cfg(vf, vsi); + vsi->req_txq = prev_queues; + vsi->req_rxq = prev_queues; + + ice_vsi_rebuild(vsi, ICE_VSI_FLAG_NO_INIT); } ice_ena_vf_mappings(vf); diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c index 749a08ccf267..8c434689e3f7 100644 --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c @@ -256,7 +256,7 @@ static void ice_vf_pre_vsi_rebuild(struct ice_vf *vf) * * It brings the VSI down and then reconfigures it with the hardware. */ -int ice_vf_reconfig_vsi(struct ice_vf *vf) +static int ice_vf_reconfig_vsi(struct ice_vf *vf) { struct ice_vsi *vsi = ice_get_vf_vsi(vf); struct ice_pf *pf = vf->pf; diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h b/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h index 91ba7fe0eaee..0c7e77c0a09f 100644 --- a/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h @@ -23,7 +23,6 @@ #warning "Only include ice_vf_lib_private.h in CONFIG_PCI_IOV virtualization files" #endif -int ice_vf_reconfig_vsi(struct ice_vf *vf); void ice_initialize_vf_entry(struct ice_vf *vf); void ice_dis_vf_qs(struct ice_vf *vf); int ice_check_vf_init(struct ice_vf *vf); From patchwork Tue Oct 8 23:00:43 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13827179 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 1C245217329 for ; Tue, 8 Oct 2024 23:01:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428474; cv=none; b=kt9FKkiF4yX4QyMAMcr6+THqlM2pHFGv9oPHBNX8Cdgq8jxoPby2ECQFwFGYk1vpUg31QUnq+MhfpVK/ntW1Xl4zFykTtuzgCU/n9GGhweGUEZMRS4TUz2SOq+SenN4CTNln6Qw3/ff7hIXmE8R4OIXCPVYRU2RrdNREGBJgys4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428474; c=relaxed/simple; bh=JM3MhC6/VzjhaoZ5ftmwqde7tQ3kXbCVKZ/x6xxqlbE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JpbsUD5JfQuF25deJ8cEqMt7M+OTxX77kO0g+7xNzd4R4+Xaf7uQtK+JXpg6b7m0A6fR4g3QoCEy3dI4LnJrpwmELswdLUCOyvM/uId6gHfk0blIaSui8sc9GAwhGyZ8asfjZ9Hm+r624gmitH+dgX2Dn9QipZqkMNcH5fMm4nQ= 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=EKEl1sFp; arc=none smtp.client-ip=192.198.163.16 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="EKEl1sFp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728428473; x=1759964473; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=JM3MhC6/VzjhaoZ5ftmwqde7tQ3kXbCVKZ/x6xxqlbE=; b=EKEl1sFpsXJpX6E05I+N9aAvGyX9DL2D0doXInHCRJgVB8M8M62ogEAN imZJu0sKbbHWVtlc8sr40TFi1clTCGgI9P4ZFIHh5/VcAPUjM3amoE+/7 OHJY1jVJfEMcNLCf42BhGqitKY1UsUCGmpznj4718ntRsZ81hS1/WhWjX v9SCzOvxCF8+dpm8Bi4YubBOBgXsZ4w4mJHeBcAANf6zc8L+9MiX9m2nn gfmMfFZ/WTzQlLuJgoaCFwWXCKLzhr/kt/trXbaNuyO0r4c5pv4WILOPX c6kCIlpHk5ux6mqHeaIHwsoF9et9qUmYurHl8XhsAvrd4Lm5QZx9JawyO A==; X-CSE-ConnectionGUID: twRPrW29Rc+SM9+r6Of8Aw== X-CSE-MsgGUID: /YAjEzvGS4ybYbPCxOUglg== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="15302425" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="15302425" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 16:01:10 -0700 X-CSE-ConnectionGUID: cf9vRFgwSF2twzTkp28EeA== X-CSE-MsgGUID: u0lc6H2IQgCy7RqruT0+mQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="106787601" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa001.fm.intel.com with ESMTP; 08 Oct 2024 16:01:05 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Aleksandr Loktionov , anthony.l.nguyen@intel.com, Arkadiusz Kubalewski , Simon Horman , Rafal Romanowski Subject: [PATCH net 5/7] i40e: Fix macvlan leak by synchronizing access to mac_filter_hash Date: Tue, 8 Oct 2024 16:00:43 -0700 Message-ID: <20241008230050.928245-6-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241008230050.928245-1-anthony.l.nguyen@intel.com> References: <20241008230050.928245-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 This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the mac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak. Fixes: fed0d9f13266 ("i40e: Fix VF's MAC Address change on VM") Reviewed-by: Arkadiusz Kubalewski Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/i40e/i40e_main.c | 1 + drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 03205eb9f925..25295ae370b2 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -1734,6 +1734,7 @@ struct i40e_mac_filter *i40e_add_mac_filter(struct i40e_vsi *vsi, struct hlist_node *h; int bkt; + lockdep_assert_held(&vsi->mac_filter_hash_lock); if (vsi->info.pvid) return i40e_add_filter(vsi, macaddr, le16_to_cpu(vsi->info.pvid)); diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c index 662622f01e31..dfa785e39458 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -2213,8 +2213,10 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf *vf, u8 *msg) vfres->vsi_res[0].qset_handle = le16_to_cpu(vsi->info.qs_handle[0]); if (!(vf->driver_caps & VIRTCHNL_VF_OFFLOAD_USO) && !vf->pf_set_mac) { + spin_lock_bh(&vsi->mac_filter_hash_lock); i40e_del_mac_filter(vsi, vf->default_lan_addr.addr); eth_zero_addr(vf->default_lan_addr.addr); + spin_unlock_bh(&vsi->mac_filter_hash_lock); } ether_addr_copy(vfres->vsi_res[0].default_mac_addr, vf->default_lan_addr.addr); From patchwork Tue Oct 8 23:00:44 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13827180 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 8A23E2178F3 for ; Tue, 8 Oct 2024 23:01:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428475; cv=none; b=YoUom343aiNWE4YX6iGsSQWNVSPACoXyZLx1R5dq9HuiLLnlNgJG+lYNt0WdgrDEYk7uvgMAfU6s/gLh246DrOp/PPv6tepBPIhQFcSh0R0NwlUu2WKZAIiCY+g/a5jYGHTH7vNoIwn9O1CxCpkcwAOE9hfzvN5tJiNjesnfwHA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428475; c=relaxed/simple; bh=J6tVzTYOw8gb1sAydGTFZ7tLQROzyrDzjCBPKCMU418=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Nwn8N+toLDJPe9Vz9htnSkbkJ4m3TZ7pmLkSAzgCX2rBIs2xWg7UsJj5LLIe63Er/gOeYBsesZUmzFnVTcEHZpSC5feDsU3hEcZbgiLxbF/lDFvPR55MDsfcQeLrBxt7rCKSlgA8IJU2cEcTXBA5nbQa2oVnkyjznqbcBMuY/BQ= 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=muTNfVfb; arc=none smtp.client-ip=192.198.163.16 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="muTNfVfb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728428474; x=1759964474; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=J6tVzTYOw8gb1sAydGTFZ7tLQROzyrDzjCBPKCMU418=; b=muTNfVfb+QXpMM2nLj20tgg6AP+KnWSM9iuO2c4/Z8LTzWJU4bYTCio3 uGMqUYuNOphgvHQ0fAHA3d8VM6BRbgALFqGt4A4nsAM1Y2EP3zPvDrc9S t1OgZqfdGnqbpRXwZRByF2ihPxQLEBS1P8JTJ6vEIh7CANRIYNk3m53fi 2xjzx+Njp/62CjAPiUz7HfkEcN5Y0OuWAlxeH7a8+lZp9tTnu5VWzTE4i 1Z0vrpWhEZuzDRzq5bmBtLh+NEGYytF865Ig6wMV8xVt4KOJxjaulbw3m 8Q6XptCalgi7yo3oz8Osy3/3wTogAPzRDCQwZwGcYf5BNDeXAeMH88Zlx A==; X-CSE-ConnectionGUID: 6MOQv2kcSCqP8+iIEVjHmQ== X-CSE-MsgGUID: 2eSf0bqzS167GQma4sp5Hg== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="15302434" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="15302434" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 16:01:11 -0700 X-CSE-ConnectionGUID: 8tiYm3RITXCESyodkx3png== X-CSE-MsgGUID: hgCRSAcMS+y5MkKMJ6Lq6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="106787605" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa001.fm.intel.com with ESMTP; 08 Oct 2024 16:01:05 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Mohamed Khalfella , anthony.l.nguyen@intel.com, yinghsu@chromium.org, Yuanyuan Zhong , Simon Horman , Pucha Himasekhar Reddy Subject: [PATCH net 6/7] igb: Do not bring the device up after non-fatal error Date: Tue, 8 Oct 2024 16:00:44 -0700 Message-ID: <20241008230050.928245-7-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241008230050.928245-1-anthony.l.nguyen@intel.com> References: <20241008230050.928245-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: Mohamed Khalfella Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up. Signed-off-by: Mohamed Khalfella Reviewed-by: Yuanyuan Zhong Fixes: 004d25060c78 ("igb: Fix igb_down hung on surprise removal") Reviewed-by: Simon Horman Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/igb/igb_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c index 1ef4cb871452..f1d088168723 100644 --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -9651,6 +9651,10 @@ static void igb_io_resume(struct pci_dev *pdev) struct igb_adapter *adapter = netdev_priv(netdev); if (netif_running(netdev)) { + if (!test_bit(__IGB_DOWN, &adapter->state)) { + dev_dbg(&pdev->dev, "Resuming from non-fatal error, do nothing.\n"); + return; + } if (igb_up(adapter)) { dev_err(&pdev->dev, "igb_up failed after reset\n"); return; From patchwork Tue Oct 8 23:00:45 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13827181 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 7EAF2217917 for ; Tue, 8 Oct 2024 23:01:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428476; cv=none; b=NBO/LNmSReX4HxvrUd2KXA8m4Wh5cuBhe6nmFmMzmAtbB9U954HgMvxSx+p2r0Eo6vrFB1FaVGANQFaTkn1RiQgpSmr5Ye6qwCGozWrgCT3GXYwAv8Q4Psqq8nYnMkRwykFrwuXaCN/toz4ASFUjzDPwrtETqeCo4mKU80asJfc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728428476; c=relaxed/simple; bh=0xK1D8s3/kwNY+pPqvR9Rv+snPRHt0bdPjaGhzN48zQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N/DHYcbQDvuGyjjKhkTum5mF0MI+5WrhGGnKUQWcVm5PO6NBbtHfOMOmPKO1s8yJYZcJiEQNJUSs5TlXmTnm3okrMmobLZMNuIb06zQ9yz46vIVKtuxyfyTS8igtAsODjjAk979qu24CaWlRELAvLWNXcs/IdqNGk2HnEjDI/pA= 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=I/4qA0oZ; arc=none smtp.client-ip=192.198.163.16 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="I/4qA0oZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728428474; x=1759964474; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0xK1D8s3/kwNY+pPqvR9Rv+snPRHt0bdPjaGhzN48zQ=; b=I/4qA0oZPXyoMLfj2KEytNcc4pH+tP3XM2bL85uNvwUS2ORuFTQ4xcX2 jfkUR/kZTKm6Et6EntqeJG7os/IGH4dxiPm2hKz3nwOGzcXgpjt62abMK mYpvh4gQbbIZLF1Dp5XRYVV03RcsM8CVosL+RhVCE3DuPw8QCYLgxR6dE uwhviiF9L8OG/+QHLCtQSo8ZX0C1BdCFgG1T7PlJmjtuV8yXYCUQmf4JB qjuTMUqp/oLsNiGp08HXIYtuh3V1m0OMp82/FvgrfZrBgawwH3E+2UgOq 6QUT1ni5kILWU9owwW4RUQchfNXu8ZtVlyNEz8pG3CgSwFgtGTeO8e7jP w==; X-CSE-ConnectionGUID: NH9jf0i7Sam00+3PQ+IRmA== X-CSE-MsgGUID: FqHsyLzaT3eAp/J8KzHj6Q== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="15302430" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="15302430" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 16:01:11 -0700 X-CSE-ConnectionGUID: 983Gs98PSn+elBIm26YCJw== X-CSE-MsgGUID: VmcsW7CgSvayJNrJ9D33fA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="106787607" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmviesa001.fm.intel.com with ESMTP; 08 Oct 2024 16:01:06 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Vitaly Lifshits , anthony.l.nguyen@intel.com, dima.ruinskiy@intel.com, Mor Bar-Gabay Subject: [PATCH net 7/7] e1000e: change I219 (19) devices to ADP Date: Tue, 8 Oct 2024 16:00:45 -0700 Message-ID: <20241008230050.928245-8-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20241008230050.928245-1-anthony.l.nguyen@intel.com> References: <20241008230050.928245-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 Sporadic issues, such as PHY access loss, have been observed on I219 (19) devices. It was found that these devices have hardware more closely related to ADP than MTP and the issues were caused by taking MTP-specific flows. Change the MAC and board types of these devices from MTP to ADP to correctly reflect the LAN hardware, and flows, of these devices. Fixes: db2d737d63c5 ("e1000e: Separate MTP board type from ADP") Signed-off-by: Vitaly Lifshits Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/e1000e/hw.h | 4 ++-- drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/hw.h b/drivers/net/ethernet/intel/e1000e/hw.h index 4b6e7536170a..fc8ed38aa095 100644 --- a/drivers/net/ethernet/intel/e1000e/hw.h +++ b/drivers/net/ethernet/intel/e1000e/hw.h @@ -108,8 +108,8 @@ struct e1000_hw; #define E1000_DEV_ID_PCH_RPL_I219_V22 0x0DC8 #define E1000_DEV_ID_PCH_MTP_I219_LM18 0x550A #define E1000_DEV_ID_PCH_MTP_I219_V18 0x550B -#define E1000_DEV_ID_PCH_MTP_I219_LM19 0x550C -#define E1000_DEV_ID_PCH_MTP_I219_V19 0x550D +#define E1000_DEV_ID_PCH_ADP_I219_LM19 0x550C +#define E1000_DEV_ID_PCH_ADP_I219_V19 0x550D #define E1000_DEV_ID_PCH_LNP_I219_LM20 0x550E #define E1000_DEV_ID_PCH_LNP_I219_V20 0x550F #define E1000_DEV_ID_PCH_LNP_I219_LM21 0x5510 diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index f103249b12fa..07e903346358 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7899,10 +7899,10 @@ static const struct pci_device_id e1000_pci_tbl[] = { { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_V17), board_pch_adp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_RPL_I219_LM22), board_pch_adp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_RPL_I219_V22), board_pch_adp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_LM19), board_pch_adp }, + { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ADP_I219_V19), board_pch_adp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_LM18), board_pch_mtp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_V18), board_pch_mtp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_LM19), board_pch_mtp }, - { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_MTP_I219_V19), board_pch_mtp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_LNP_I219_LM20), board_pch_mtp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_LNP_I219_V20), board_pch_mtp }, { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_LNP_I219_LM21), board_pch_mtp },