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] [day] [month] [year] [list]

Message-ID: <da2faa88-7d81-4b2b-bf2e-f7a4e4a22615@intel.com>
Date: Wed, 11 Feb 2026 10:46:35 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>, 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>,
	<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



On 2/11/2026 9:13 AM, Alexander Lobakin wrote:
> 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.
> 

I wouldn't trust an absence of reports in the case of subtle locking 
issues like this. At least one of the reports here is obviously valid:

ice_vsi_cfg_def_locked holds the netdev lock but calls 
ice_vsi_free_q_vectors in its goto cleanup logic.

Its a mistake in cleanup flow which is likely untested. Of course users 
haven't reproduced this because they haven't managed to get a failure
that would trigger a cleanup.

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

I agree it is important to take the AI report with a grain of salt, and 
it is incredibly frustrating when you see a bogus report that 
hallucinated some data.

Unfortunately, in this case its a real (if extremely unlikely to trigger 
in practice) issue.

> 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