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

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.