linux-kernel - Re: [PATCH v5 0/2] mac80211: Trigger disconnect for STA during target hardware restart

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: <Yiecyl7Dd6AXJhN+@google.com>
Date:   Tue, 8 Mar 2022 10:13:30 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Youghandhar Chintala <youghand@...eaurora.org>
Cc:     ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        linux-kernel@...r.kernel.org, pillair@...eaurora.org,
        dianders@...omium.org, kuabhs@...omium.org, mpubbise@...eaurora.org
Subject: Re: [PATCH v5 0/2] mac80211: Trigger disconnect for STA during
 target hardware restart

On Tue, Mar 08, 2022 at 05:23:23PM +0530, Youghandhar Chintala wrote:
> Currently in case of target hardware restart ,we just reconfig and
> re-enable the security keys and enable the network queues to start
> data traffic back from where it was interrupted.
> 
> Many ath10k wifi chipsets have sequence numbers for the data
> packets assigned by firmware and the mac sequence number will
> restart from zero after target hardware restart leading to mismatch
> in the sequence number expected by the remote peer vs the sequence
> number of the frame sent by the target firmware.
> 
> This mismatch in sequence number will cause out-of-order packets
> on the remote peer and all the frames sent by the device are dropped
> until we reach the sequence number which was sent before we restarted
> the target hardware
> 
> In order to fix this, we trigger a disconnect in case of hardware
> restart. After this there will be a fresh connection and thereby
> avoiding the dropping of frames by remote peer.
> 
> The right fix would be to pull the entire data path into the host
> which is not feasible or would need lots of complex/inefficient
> datapath changes.
> 
> ---
> Changes from v3:
> - Fixed commit text errors
> - Remove excess space in "hardware  restart"
> - Removed blank line between the function description and the arguments

For whatever it's worth, the series looks good to me:

Reviewed-by: Brian Norris <briannorris@...omium.org>