Re: [PATCH net v2] gve: use gve_schedule_reset() on AdminQ flow rule timeout

["Rénich Bon Ćirić" <renich@evalinux.com>]

On Mon, 10 Aug 2026 14:13:00 -0700, Harshitha Ramamurthy wrote:
> gve_reset() does not acquire the rtnl_lock(). Also, there is no inner
> driver lock context that is acquired at this point. The inner driver
> lock context that the AI is complaining about is possibly
> priv->adminq_lock but that is already released on error by
> gve_adminq_execute_cmd(). gve_reset() is also written in such a way
> that the onus is on the caller to acquire the appropriate locks -
> either through the ethtool core when calling
> gve_user_reset()/gve_set_rxnfc() or explicitly by gve_handle_reset().
> 
> Sashiko has also called out a few issues this change could introduce.
> Considering this issue hasn't actually been encountered in the wild,
> there is no lockdep splat and the commit message is inaccurate, I
> don't think this qualifies for the net tree.
> 
> For the net-next tree, a more holistic change is in the works for the
> reset path that also changes this path and removes the synchronous
> reset anyway.

Understood. Thanks for clarifying the gve_reset() lock mechanics and
adminq_lock release behavior.

We will drop this patch from the net tree and look out for Google's
upcoming reset path refactoring in net-next.