Re: [net-next,3/9] ice: migrate to netdev ops lock

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 11 Feb 2026 14:51:56 +0100 Alexander Lobakin wrote:
> >> +free_coalesce:
> >> +	kfree(coalesce);
> >> +decfg:
> >> +	if (ret)
> >> +		ice_vsi_decfg(vsi);  
> > 
> > Should this be ice_vsi_decfg_locked(vsi)?
> > 
> > ice_vsi_rebuild_locked() is called with the netdev lock already held
> > (either by the ice_vsi_rebuild() wrapper or by callers like
> > ice_vsi_recfg_qs()). The error path at label 'decfg:' calls ice_vsi_decfg()
> > which tries to acquire the lock again:
> > 
> > ice_vsi_rebuild_locked() [netdev lock held]  
> >   -> ice_vsi_decfg()
> >      -> netdev_lock(dev)  /* deadlock - already held */  
> > 
> > This would deadlock when an error occurs after ice_vsi_cfg_def_locked()
> > succeeds but a later operation fails.  
> 
> Tony also fed the series to AI, two times, and each time he got a
> different answer.
> The series was on iwl-next for 1.5 months and only one bug was reported,
> which I fixed immediately.
> 
> I can take a look into this, but wouldn't be better if we take the
> series now and then have 2 months to fix bugs if any appears?

I understand the frustration, but unless the review is a false positive
I don't see how we can ignore it.

Looking at the PR rate from Intel I suspect you may be better off
pointing your frustration at the internal process? There seems to 
be a net-next PR every 2 weeks in 2026. It's not like the 1.5 mo 
was spent waiting on upstream?