netdev - Re: RE: [Intel-wired-lan] [PATCH iwl-net v2 2/2] ixgbe: don't initialize aci lock in ixgbe_recovery

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: <20251211152105.96440-1-enjuk@amazon.com>
Date: Fri, 12 Dec 2025 00:20:58 +0900
From: Kohei Enju <enjuk@...zon.com>
To: <aleksandr.loktionov@...el.com>
CC: <andrew+netdev@...n.ch>, <anthony.l.nguyen@...el.com>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <enjuk@...zon.com>,
	<horms@...nel.org>, <intel-wired-lan@...ts.osuosl.org>,
	<jacob.e.keller@...el.com>, <jedrzej.jagielski@...el.com>, <kohei@...uk.org>,
	<kuba@...nel.org>, <netdev@...r.kernel.org>, <pabeni@...hat.com>,
	<przemyslaw.kitszel@...el.com>, <stefan.wegrzyn@...el.com>
Subject: Re: RE: [Intel-wired-lan] [PATCH iwl-net v2 2/2] ixgbe: don't initialize aci lock in ixgbe_recovery_probe()

On Thu, 11 Dec 2025 10:12:19 +0000, Loktionov, Aleksandr wrote:

>> Subject: [Intel-wired-lan] [PATCH iwl-net v2 2/2] ixgbe: don't
>> initialize aci lock in ixgbe_recovery_probe()
>> 
>> hw->aci.lock is already initialized in ixgbe_sw_init(), so
>> ixgbe_recovery_probe() doesn't need to initialize the lock. This
>You claim that ixgbe_sw_init() initializes hw->aci.lock but don't provide evidence(s).
>Can you?

Hi Alex, thank you for reviewing!

Yeah, I claim that because currently ixgbe_recovery_probe() is only
called from ixgbe_probe(), and this is called after ixgbe_sw_init().
Also I don't expect ixgbe_recovery_probe() would be called from other
contexts in the future.

We confirmed the that double initialization would occur in the
context[1], but are there any recommended solutions we can adopt?

I understand that double initialization doesn't always introduce
realistic issue because it would be problematic only when reinialization
is done while the lock is held, but it's a fact that actually
unnecessary initialization is done in ixgbe_recovery_probe().

I believe this change would be right, but maybe we should ask Jedrzej
for the intention of mutex_init() in ixgbe_recovery_probe(), and
possibility that ixgbe_recovery_probe() would be called from any other
contexts.

[1] https://lore.kernel.org/all/b5787c94-2ad0-4519-9cdb-5e82acfebe05@intel.com/