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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3b134d22-30ec-4532-9b89-f96761d3abc9@intel.com>
Date: Wed, 11 Feb 2026 18:13:03 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <anthony.l.nguyen@...el.com>, <netdev@...r.kernel.org>, <sdf@...ichev.me>,
	<andrew+netdev@...n.ch>, <ast@...nel.org>, <sx.rinitha@...el.com>,
	<horms@...nel.org>, <yury.norov@...il.com>, <john.fastabend@...il.com>,
	<kohei@...uk.jp>, <przemyslaw.kitszel@...el.com>, <richardcochran@...il.com>,
	<alexander.nowlin@...el.com>, <daniel@...earbox.net>,
	<maciej.fijalkowski@...el.com>, <nxne.cnse.osdt.itp.upstreaming@...el.com>,
	<edumazet@...gle.com>, <aleksandr.loktionov@...el.com>,
	<marcin.szycik@...ux.intel.com>, <hawk@...nel.org>,
	<jacob.e.keller@...el.com>, <magnus.karlsson@...el.com>,
	<pmenzel@...gen.mpg.de>, <pabeni@...hat.com>, <bpf@...r.kernel.org>,
	<davem@...emloft.net>, <andriy.shevchenko@...ux.intel.com>
Subject: Re: [net-next,3/9] ice: migrate to netdev ops lock

From: Jakub Kicinski <kuba@...nel.org>
Date: Wed, 11 Feb 2026 08:55:14 -0800

> 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?

I'm not frustrated at all :> I mentioned those 1.5 months only to say
that during that time, none of the users of our tree faced any bugs,
except one case which was fixed a long ago.

Anyway, this last PR was just a try to squeeze in at the end of the
window to compensate that it took a bit too long for the val to test
the series. It's not a problem at all if it won't.
Maybe I'll even add support for zcrx large buffers in meantime instead
of sending a followup later.

I can't say it's a false positive, but I can't confirm the AI is
absolutely correct here. At least a couple places mentioned that
"shouldn't work" in fact works. It's not just me being Sarah Connor when
it comes to AI, I just don't want people to trust it too much or authors
to waste time proving that AI is wrong.

Your call whether to drop it or take (this PR also contains several
patches not related to netmem, I think they shouldn't be dropped?).

Thanks,
Olek