On Thu, Oct 08, 2026 at 08:57:54PM +0800, Linkui Xiao wrote: > From: Linkui Xiao <[email protected]> > > ice_init_vf_vsi_res() reserves vf->num_msix vectors out of > pf->virt_irq_tracker with ice_virt_get_irqs() as its very first step, > but neither of the two error paths below it gives them back. A NULL > from ice_vf_vsi_setup() returns -ENOMEM straight away, and the > release_vsi label only releases the VSI. > > ice_start_vfs() leaks the same vectors. Its teardown loop undoes the > queue mappings and the VF VSI of the VFs it already started, and the > eswitch attach failure path releases the VSI of the VF it is working > on, but neither calls ice_virt_free_irqs(). The caller then runs > ice_free_vf_entries(), which drops the last reference on every VF, so > nothing further down the error path can release the reservation > either. > > The tracker bitmap is only freed in ice_deinit_virt_irq_tracker(), so > the leaked vectors stay reserved for the whole lifetime of the driver > instance. Every failed "echo N > sriov_numvfs" permanently shrinks the > pool that ice_set_per_vf_res() divides up, and after enough retries > ice_virt_get_irqs() fails with -ENOENT for good even though the > hardware vectors are idle. ice_dis_vf_mappings() meanwhile re-points > GLINT_VECT2FUNC of exactly those vectors back at the PF while the > bitmap still books them to the VF. > > Release the vectors on all three paths, the way ice_free_vfs() does > for a VF that is torn down normally. > > Found by code inspection of the VF setup and teardown error paths. It > was not triggered and no stack trace or error message was observed. > Compile-tested only, not run on hardware. > > Fixes: 4d38cb44bd32 ("ice: manage VFs MSI-X using resource tracking") > Cc: [email protected] > Signed-off-by: Linkui Xiao <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
