[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240607121552.15127-1-dawid.osuchowski@linux.intel.com>
Date: Fri, 7 Jun 2024 14:15:52 +0200
From: Dawid Osuchowski <dawid.osuchowski@...ux.intel.com>
To: intel-wired-lan@...ts.osuosl.org
Cc: netdev@...r.kernel.org,
Ngai-Mint Kwan <ngai-mint.kwan@...el.com>,
Mateusz Polchlopek <mateusz.polchlopek@...el.com>,
Pawel Chmielewski <pawel.chmielewski@...el.com>,
Simon Horman <horms@...nel.org>,
Dawid Osuchowski <dawid.osuchowski@...ux.intel.com>
Subject: [PATCH iwl-net v5] ice: Do not get coalesce settings while in reset
From: Ngai-Mint Kwan <ngai-mint.kwan@...el.com>
Getting coalesce settings while reset is in progress can cause NULL
pointer deference bug.
If under reset, abort get coalesce for ethtool.
We cannot use ice_wait_for_reset() since both the ethtool handler and the
adapter reset flow call rtnl_lock() during operation. If we wait for
reset completion inside of an ethtool handling function such as
ice_get_coalesce(), the wait will always timeout due to reset being
blocked by rtnl_lock() inside of ice_queue_set_napi() (which is called
during reset process), and in turn we will always return -EBUSY anyways,
with the added hang time of the timeout value.
Fixes: 67fe64d78c43 ("ice: Implement getting and setting ethtool coalesce")
Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@...el.com>
Reviewed-by: Mateusz Polchlopek <mateusz.polchlopek@...el.com>
Signed-off-by: Pawel Chmielewski <pawel.chmielewski@...el.com>
Reviewed-by: Simon Horman <horms@...nel.org>
Signed-off-by: Dawid Osuchowski <dawid.osuchowski@...ux.intel.com>
---
Changes since v1:
* Added "Fixes:" tag
Changes since v2:
* Rebased over current IWL net branch
* Confirmed that the issue previously reported for this patch [1] by
Himasekhar Reddy Pucha was caused by other, internally tracked issue
Changes since v3:
* Using ice_wait_for_reset() instead of returning -EBUSY
Changes since v4:
* Rebased over current IWL net branch
* Rollback the use of ice_wait_for_reset() due to rtnl_lock() deadlock
issue described in [2] and commit msg
[1] https://lore.kernel.org/netdev/BL0PR11MB3122D70ABDE6C2ACEE376073BD90A@BL0PR11MB3122.namprd11.prod.outlook.com/
[2] https://lore.kernel.org/netdev/20240501195641.1e606747@kernel.org/T/#m1629ecfe88d26551852c5c97982cd10314991422
---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index 62c8205fceba..2ffe864a364c 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -3810,6 +3810,9 @@ __ice_get_coalesce(struct net_device *netdev, struct ethtool_coalesce *ec,
struct ice_netdev_priv *np = netdev_priv(netdev);
struct ice_vsi *vsi = np->vsi;
+ if (ice_is_reset_in_progress(vsi->back->state))
+ return -EBUSY;
+
if (q_num < 0)
q_num = 0;
--
2.44.0
Powered by blists - more mailing lists