[iwl-net,v5] ice: Do not get coalesce settings while in reset

Commit Message

Dawid Osuchowski June 7, 2024, 12:15 p.m. UTC

From: Ngai-Mint Kwan <[e-mail]>

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 <[e-mail]>
Reviewed-by: Mateusz Polchlopek <[e-mail]>
Signed-off-by: Pawel Chmielewski <[e-mail]>
Reviewed-by: Simon Horman <[e-mail]>
Signed-off-by: Dawid Osuchowski <[e-mail]>
---
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/[e-mail]/
[2] https://lore.kernel.org/netdev/[e-mail]/T/#m1629ecfe88d26551852c5c97982cd10314991422
---
 drivers/net/ethernet/intel/ice/ice_ethtool.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Pucha, HimasekharX Reddy June 10, 2024, 9:53 a.m. UTC | #1

> -----Original Message-----
> From: Intel-wired-lan <[e-mail]> On Behalf Of Dawid Osuchowski
> Sent: Friday, June 7, 2024 5:46 PM
> To: [e-mail]
> Cc: Kwan, Ngai-mint <[e-mail]>; [e-mail]; Chmielewski, Pawel <[e-mail]>; Simon Horman <[e-mail]>; Polchlopek, Mateusz <[e-mail]>; Dawid Osuchowski <[e-mail]>
> Subject: [Intel-wired-lan] [PATCH iwl-net v5] ice: Do not get coalesce settings while in reset
>
> From: Ngai-Mint Kwan <[e-mail]>
>
> 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 <[e-mail]>
> Reviewed-by: Mateusz Polchlopek <[e-mail]>
> Signed-off-by: Pawel Chmielewski <[e-mail]>
> Reviewed-by: Simon Horman <[e-mail]>
> Signed-off-by: Dawid Osuchowski <[e-mail]>
> ---
> 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/[e-mail]/
> [2] https://lore.kernel.org/netdev/[e-mail]/T/#m1629ecfe88d26551852c5c97982cd10314991422
> ---
>  drivers/net/ethernet/intel/ice/ice_ethtool.c | 3 +++
>  1 file changed, 3 insertions(+)
>

Tested-by: Pucha Himasekhar Reddy <[e-mail]> (A Contingent worker at Intel)

Jakub Kicinski June 11, 2024, 2:47 a.m. UTC | #2

On Fri,  7 Jun 2024 14:15:52 +0200 Dawid Osuchowski wrote:
> 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.

Why does the reset not call netif_device_detach()?
Then core will know not to call the driver.

> Fixes: 67fe64d78c43 ("ice: Implement getting and setting ethtool coalesce")

Isn't ice_queue_set_napi() much more recent than this commit?

Dawid Osuchowski June 14, 2024, 11:50 a.m. UTC | #3

On 11.06.2024 04:47, Jakub Kicinski wrote:

> Why does the reset not call netif_device_detach()?
> Then core will know not to call the driver.
Will use this approach in new patch, thanks.

--Dawid

Patch

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;