Re: [PATCH net 1/3] i40e: keep q_vectors array in sync with channel count changes

[Maciej Fijalkowski <maciej.fijalkowski@intel.com>]

On Fri, Jun 05, 2026 at 04:39:34PM -0700, Jakub Kicinski wrote:
> On Fri, 5 Jun 2026 11:01:19 -0700 Tony Nguyen wrote:
> > > Should the new err_lump label, and the existing err_vsi exits from the
> > > two allocation steps above, instead unwind through the err_rings block
> > > (unregister_netdev / free_netdev / i40e_devlink_destroy_port /
> > > i40e_aq_delete_element) the way i40e_vsi_setup()'s err_msix path does?
> > > 
> > > The pre-patch code had the same defective err_vsi target for the
> > > qp_pile and arrays paths, but the patch adds two new failure points
> > > (the unconditional q_vectors kzalloc and the new
> > > i40e_vsi_setup_vectors() call) that route into it during reset
> > > rebuild, where vsi->netdev is already registered.  
> >  
> > This does seem valid, but as mentioned by Sashiko the pre-patch code has 
> > the same target/issue. There's a recent submission [1], with changes 
> > requested, that should cover this. Did you want to take this now or wait 
> > and have it sent with this other one?
> 
> Hm. I convinced myself yesterday that the old code did _not_ 
> have the issue because it was pass false as the second arg to
> i40e_vsi_{alloc,free}_arrays() ? Good chance that I misread,
> it's tricky code. As much as I would love to apply this to prevent 
> the deadlock in NIPA - let's wait for the follow up. I'll pick up 
> the other two patches from this series off the list.

FWIW it was our beloved "pre-existing issue", alloc arrays could fail at
ring memory allocation and bail out without de-registering netdev.

Regardless, I'm gonna send a v4 with preceding patch that should fix
this...

>