Re: [PATCH net 2/2] net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] In `mana_create_vport()`, if `mana_create_txq()` fails, the function returns the error directly without unwinding the previously successful `mana_cfg_vport()` and `mana_pf_register_hw_vport()`. Similarly, if `mana_cfg_vport()` fails, it returns the error without unwinding `mana_pf_register_hw_vport()`. This leaks firmware vPort registrations and leaves `apc->vport_use_count > 0`, leading to a permanent `-EBUSY` error on all future attempts to open the device.
--

commit 22337dc3f6a86510c8d8b1e096424ad2f6000592
Author: Aditya Garg <gargaditya@linux.microsoft.com>

net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check

This commit fixes an issue where mana_destroy_txq() attempts to destroy a
WQ object using INVALID_MANA_HANDLE if allocation fails earlier. It adds
a check to verify the handle is valid before calling mana_destroy_wq_obj().

> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index db14357d3732e..4a2cd800111e7 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -2351,7 +2351,8 @@ static void mana_destroy_txq(struct mana_port_context *apc)
>  			netif_napi_del_locked(napi);
>  			apc->tx_qp[i]->txq.napi_initialized = false;
>  		}
> -		mana_destroy_wq_obj(apc, GDMA_SQ, apc->tx_qp[i]->tx_object);
> +		if (apc->tx_qp[i]->tx_object != INVALID_MANA_HANDLE)
> +			mana_destroy_wq_obj(apc, GDMA_SQ, apc->tx_qp[i]->tx_object);
>  
>  		mana_deinit_cq(apc, &apc->tx_qp[i]->tx_cq);
>  

[Severity: High]
This is a pre-existing issue, but while reviewing the error paths that lead
to mana_destroy_txq(), I noticed a potential resource leak in
mana_create_vport().

If mana_create_txq() fails, the function returns the error directly without
unwinding the previously successful mana_cfg_vport() and
mana_pf_register_hw_vport():

drivers/net/ethernet/microsoft/mana/mana_en.c:mana_create_vport() {
    ...
	err = mana_cfg_vport(apc, gd->pdid, gd->doorbell);
	if (err)
		return err;

	return mana_create_txq(apc, net);
}

The same applies if mana_cfg_vport() fails, as it returns the error without
unwinding mana_pf_register_hw_vport().

Because mana_alloc_queues() propagates this error without calling
mana_destroy_vport() or unwinding the partial initialization:

drivers/net/ethernet/microsoft/mana/mana_en.c:mana_alloc_queues() {
    ...
	err = mana_create_vport(apc, ndev);
	if (err) {
		netdev_err(ndev, "Failed to create vPort %u : %d\n", apc->port_idx, err);
		return err;
	}
    ...
}

Does this leak firmware vPort registrations and leave apc->vport_use_count > 0,
leading to a permanent -EBUSY error on all future attempts to open the device?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604080137.1995269-1-gargaditya@linux.microsoft.com?part=2