netdev - Re: [PATCH net-next 1/4] ionic: catch transition back to RUNNING with fw

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: <20220217201213.3e794f82@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 17 Feb 2022 20:12:13 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, drivers@...sando.io
Subject: Re: [PATCH net-next 1/4] ionic: catch transition back to RUNNING
 with fw_generation 0

On Thu, 17 Feb 2022 14:02:49 -0800 Shannon Nelson wrote:
> In some graceful updates that get initially triggered by the
> RESET event, especially with older firmware, the fw_generation
> bits don't change but the fw_status is seen to go to 0 then back
> to 1.  However, the driver didn't perform the restart, remained
> waiting for fw_generation to change, and got left in limbo.
> 
> This is because the clearing of idev->fw_status_ready to 0
> didn't happen correctly as it was buried in the transition
> trigger: since the transition down was triggered not here
> but in the RESET event handler, the clear to 0 didn't happen,
> so the transition back to 1 wasn't detected.
> 
> Fix this particular case by bringing the setting of
> idev->fw_status_ready back out to where it was before.
> 
> Fixes: 398d1e37f960 ("ionic: add FW_STOPPING state")
> Signed-off-by: Shannon Nelson <snelson@...sando.io>

This looks like a fix, and should go separately to net.
Is there a reason behind posting together? The other patches
don't even depend on this one.