netdev - Re: [net PATCH v2 0/8] fbnic: FW IPC Mailbox fixes

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: <20250507184128.33d5c4ad@kernel.org>
Date: Wed, 7 May 2025 18:41:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
 horms@...nel.org
Subject: Re: [net PATCH v2 0/8] fbnic: FW IPC Mailbox fixes

On Tue, 06 May 2025 08:59:33 -0700 Alexander Duyck wrote:
> This series is meant to address a number of issues that have been found in
> the FW IPC mailbox over the past several months.
> 
> The main issues addressed are:
> 1. Resolve a potential race between host and FW during initialization that
> can cause the FW to only have the lower 32b of an address.
> 2. Block the FW from issuing DMA requests after we have closed the mailbox
> and before we have started issuing requests on it.
> 3. Fix races in the IRQ handlers that can cause the IRQ to unmask itself if
> it is being processed while we are trying to disable it.
> 4. Cleanup the Tx flush logic so that we actually lock down the Tx path
> before we start flushing it instead of letting it free run while we are
> shutting it down.
> 5. Fix several memory leaks that could occur if we failed initialization.
> 6. Cleanup the mailbox completion if we are flushing Tx since we are no
> longer processing Rx.
> 7. Move several allocations out of a potential IRQ/atomic context.
> 
> There have been a few optimizations we also picked up since then. Rather
> than split them out I just folded them into these diffs. They mostly 
> address minor issues such as how long it takes to initialize and/or fail so
> I thought they could probably go in with the rest of the patches. They
> consist of:
> 1. Do not sleep more than 20ms waiting on FW to respond as the 200ms value 
> likely originated from simulation/emulation testing.
> 2. Use jiffies to determine timeout instead of sleep * attempts for better
> accuracy.

Reviewed-by: Jakub Kicinski <kuba@...nel.org>