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