Re: [PATCH net-next v11 1/6] net: mana: Create separate EQs for each vPort

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing rollback of `mana_pf_register_hw_vport()` on failure in `mana_create_vport()` leads to hardware resource leak.
- [High] Destroying an RSS QP disables RX steering for the entire physical vport, breaking any other active QPs.
--

commit 81a114514be59954addf46b0c28014c7c1c47694
Author: Long Li <longli@microsoft.com>
Subject: net: mana: Create separate EQs for each vPort

The patch moves EQ definition from mana_context to mana_port_context and
removes EQ sharing among vPorts to prepare for dedicated MSI-X vectors. It
also ensures RSS QPs take a vport reference to guarantee EQs outlive QP
consumers. Finally, cross-port PD sharing is explicitly rejected and
mana_set_channels is serialized against RDMA vport configuration.

> diff --git a/drivers/infiniband/hw/mana/qp.c b/drivers/infiniband/hw/mana/qp.c
> index 0fbcf449c134b..d9a0bf8b2bc9c 100644
> --- a/drivers/infiniband/hw/mana/qp.c
> +++ b/drivers/infiniband/hw/mana/qp.c
[ ... ]
> @@ -817,6 +841,8 @@ static int mana_ib_destroy_qp_rss(struct mana_ib_qp *qp,
>  		mana_destroy_wq_obj(mpc, GDMA_RQ, wq->rx_object);
>  	}
>  
> +	mana_ib_uncfg_vport(mdev, pd, qp->port);
> +

[Severity: High]
This is a pre-existing issue, but since this patch explicitly adds
vport_use_count refcounting to allow multiple QPs to share the same physical
vport, does the unconditional call to mana_disable_vport_rx() earlier in this
function break other active QPs?

If multiple QPs are active, destroying a single RSS QP will globally disable
receive steering for the entire hardware vport. Will this silently blackhole
all receive traffic for the remaining QPs on that port?

>  	return 0;
>  }
>  
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index 82f1461a48e93..7c776f115f5aa 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
[ ... ]
> @@ -2913,11 +2922,7 @@ static int mana_create_vport(struct mana_port_context *apc,
>  			return err;
>  	}
>  
> -	err = mana_cfg_vport(apc, gd->pdid, gd->doorbell);
> -	if (err)
> -		return err;
> -
> -	return mana_create_txq(apc, net);
> +	return mana_cfg_vport(apc, gd->pdid, gd->doorbell, false);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but the new exclusivity logic
makes it deterministically triggerable. If mana_cfg_vport() fails (which it
now will with -EBUSY if the RDMA driver currently holds the vport), does this
leak the hardware vport registration?

The function returns the error directly without rolling back
mana_pf_register_hw_vport() on failure. Because mana_cfg_vport() can now be
forced to fail deterministically, could a user with CAP_NET_ADMIN repeatedly
toggle the Ethernet interface state while holding a raw QP, leaking a hardware
vport registration each time and exhausting firmware resources?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260523020258.1107742-1-longli@microsoft.com?part=1