Re: [PATCH net-next v3 14/15] ibmveth: Wire ethtool set_channels to MQ RX queue resize

[Simon Horman <horms@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ibmveth: Wire ethtool set_channels to MQ RX queue resize

Expose incremental RX resize through ethtool channel control.
get_channels() reports rx_count from adapter->num_rx_queues and max_rx
as IBMVETH_MAX_RX_QUEUES when MQ firmware is enabled, else 1.
set_channels() validates rx_count is within 1..IBMVETH_MAX_RX_QUEUES.

> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
> index ac4d89a66a8db..50a332ab83fd3 100644
> --- a/drivers/net/ethernet/ibm/ibmveth.c
> +++ b/drivers/net/ethernet/ibm/ibmveth.c
> @@ -2534,19 +2534,69 @@ static int ibmveth_set_channels(struct net_device *netdev,
>  				struct ethtool_channels *channels)
>  {
>  	struct ibmveth_adapter *adapter = netdev_priv(netdev);
[ ... ]
> -	if (!(netdev->flags & IFF_UP))
> +	if (!(netdev->flags & IFF_UP)) {
> +		if (goal_rx > 1 && !adapter->multi_queue) {
[ ... ]
> +		/* Stash desired RX count; open() publishes it via
> +		 * netif_set_real_num_rx_queues() after queue registration.
> +		 */
> +		if (goal_rx != adapter->num_rx_queues)
> +			adapter->num_rx_queues = goal_rx;
> +
>  		return netif_set_real_num_tx_queues(netdev, goal);

[Severity: Medium]
If netif_set_real_num_tx_queues() fails and returns an error, the TX
configuration command will fail, but the RX queue count has already been
permanently modified in adapter->num_rx_queues. Will this leave the device in
an inconsistent state where the new RX count is applied on the next open
despite the command failing?

> +	}
[ ... ]
> +	if (goal_rx != old_rx) {
> +		rc = ibmveth_resize_rx_queues_incremental(adapter, goal_rx,
> +							  rxq_entries);

[Severity: High]
Does this new ethtool scale-down path expose an interrupt storm?

Looking at ibmveth_resize_rx_queues_incremental(), when scaling down queues it
disables NAPI before disabling the hardware interrupt:

drivers/net/ethernet/ibm/ibmveth.c:ibmveth_resize_rx_queues_incremental() {
    ...
		for (i = new_count; i < old_count; i++)
			napi_disable(&adapter->napi[i]);

		for (i = new_count; i < old_count; i++)
			ibmveth_drain_rx_queue(adapter, i);

		synchronize_net();
    ...
		/* Disable hypervisor interrupts and wait for handlers to complete
		 * before updating num_rx_queues.
		 */
		for (i = new_count; i < old_count; i++) {
			ibmveth_disable_irq(adapter, i);
    ...
}

If the hypervisor delivers a packet during this window, ibmveth_interrupt()
will execute. Since NAPI is disabled, napi_schedule_prep() fails, causing the
handler to return IRQ_HANDLED without disabling the hardware interrupt. Will
this leave the virtual interrupt asserted and force an infinite interrupt loop?

> +		if (rc) {
> +			netdev_err(netdev, "Failed to resize RX queues: %d\n", rc);
> +			return rc;
> +		}
> +	}
>  
>  	/* We have IBMVETH_MAX_QUEUES netdev_queue's allocated
>  	 * but we may need to alloc/free the ltb's.
>  	 */

[Severity: High]
This is a pre-existing issue, but does this function use an uninitialized
variable in the error path?

When decreasing the number of TX queues (goal < old), the allocation loop for
(i = old; i < goal; i++) is skipped, leaving 'i' uninitialized. If
netif_set_real_num_tx_queues() then fails, the error path assigns old = i;. 

The cleanup loop then uses this garbage value:
	for (i = old; i > goal; i--) {
		if (adapter->tx_ltb_ptr[i - 1])

Will this access adapter->tx_ltb_ptr out of bounds and pass arbitrary pointers
to ibmveth_free_tx_ltb()?

> @@ -2580,7 +2630,7 @@ static int ibmveth_set_channels(struct net_device *netdev,
>  
>  	netif_tx_wake_all_queues(netdev);
>  
> -	return rc;
> +	return 0;

[Severity: High]
Does this unconditional return of 0 mask TX queue configuration failures?

If applying the new TX queue count via netif_set_real_num_tx_queues() fails,
the code handles it locally, but the function exits with 0 regardless. Will
this mislead userspace into believing the TX channel count was successfully
modified?

>  }