[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7dGFLSom9mnWFdB@hog>
Date: Thu, 20 Feb 2025 16:11:16 +0100
From: Sabrina Dubroca <sd@...asysnail.net>
To: Stanislav Fomichev <sdf@...ichev.me>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com,
Saeed Mahameed <saeed@...nel.org>
Subject: Re: [PATCH net-next v5 03/12] net: hold netdev instance lock during
queue operations
2025-02-19, 12:27:10 -0800, Stanislav Fomichev wrote:
> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> index 533e659b15b3..cf9bd08d04b2 100644
> --- a/drivers/net/ethernet/google/gve/gve_main.c
> +++ b/drivers/net/ethernet/google/gve/gve_main.c
> @@ -1886,7 +1886,7 @@ static void gve_turndown(struct gve_priv *priv)
> netif_queue_set_napi(priv->dev, idx,
> NETDEV_QUEUE_TYPE_TX, NULL);
>
> - napi_disable(&block->napi);
> + napi_disable_locked(&block->napi);
I don't think all the codepaths that can lead to gve_turndown have the
required netdev_lock():
gve_resume -> gve_reset_recovery -> gve_turndown
gve_user_reset -> gve_reset -> gve_reset_recovery
(and nit:) There's also a few places in the series (bnxt, ethtool
calling __netdev_update_features) where the lockdep
annotation/_locked() variant gets introduced before the patch adding
the corresponding lock.
--
Sabrina
Powered by blists - more mailing lists