Re: [PATCH net-next v2 02/15] gve: refactor initialization with helper functions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] gve_verify_driver_compatibility() is incorrectly skipped during device reset recovery, causing the device to lose driver capability context.
--

commit 8cee6a7e999b446ef0c02854dce95bbc44f444e8
Author: Harshitha Ramamurthy <hramamurthy@google.com>
gve: refactor initialization with helper functions

This commit refactors gve_probe() and gve_init_priv() to commonize code
using helper functions gve_set_num_ntfy_blks() and gve_set_num_queues().
It also reorders code to combine lines that accomplish similar objectives
and moves setting HW-GRO and UDP GSO support into gve_init_priv().

> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> index 30bf6df4ebc58..b9542ef36b297 100644
> --- a/drivers/net/ethernet/google/gve/gve_main.c
> +++ b/drivers/net/ethernet/google/gve/gve_main.c

[ ... ]

> @@ -2470,18 +2437,73 @@ static int gve_init_priv(struct gve_priv *priv, bool skip_describe_device)

[ ... ]

> +static int gve_init_priv(struct gve_priv *priv, bool skip_describe_device)
> +{
> +	int err;
> +
> +	/* Set up the adminq */
> +	err = gve_adminq_alloc(&priv->pdev->dev, priv);
> +	if (err) {
> +		dev_err(&priv->pdev->dev,
> +			"Failed to alloc admin queue: err=%d\n", err);
> +		return err;
> +	}
> +
> +	priv->num_registered_pages = 0;
> +
> +	if (skip_describe_device)
> +		goto setup_device;
> +
> +	err = gve_verify_driver_compatibility(priv);

[Severity: High]
Does moving this driver compatibility check below the early-exit bypass the
critical capability handshake during reset recovery?

When a device reset occurs, the hardware clears its internal state. In the
baseline code, gve_verify_driver_compatibility() was called unconditionally
at the beginning of gve_init_priv(), ensuring the device was repopulated
with the driver's capabilities.

By placing it after the skip_describe_device check, the driver capability
handshake appears to be skipped during reset recovery. This leaves the
hardware unaware of the driver's features, which can cause it to reject
subsequent configuration commands or misinterpret descriptors, potentially
resulting in a denial of service until the module is reloaded.

Is it intentional to omit this handshake during recovery?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602235900.3050782-1-hramamurthy@google.com?part=2