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 <[email protected]> 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/[email protected]?part=2
