linux-kernel - Re: [PATCH v4 1/2] mac80211: Add support to trigger sta disconnect on 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7ac0be6d-35f1-cab3-0ab3-c06367a28ed1@quicinc.com>
Date:   Thu, 3 Mar 2022 08:44:51 -0800
From:   Jeff Johnson <quic_jjohnson@...cinc.com>
To:     Youghandhar Chintala <youghand@...eaurora.org>,
        <ath10k@...ts.infradead.org>
CC:     <linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <pillair@...eaurora.org>, <dianders@...omium.org>,
        <kuabhs@...omium.org>, <briannorris@...omium.org>,
        <mpubbise@...eaurora.org>
Subject: Re: [PATCH v4 1/2] mac80211: Add support to trigger sta disconnect on
 hardware restart

On 3/3/2022 3:55 AM, 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 sta disconnect, in case of target
> hw 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 changes and
> will still be inefficient.
> 
> Tested on ath10k using WCN3990, QCA6174
> 
> Signed-off-by: Youghandhar Chintala <youghand@...eaurora.org>
> ---
>   include/net/mac80211.h     | 11 +++++++++++
>   net/mac80211/ieee80211_i.h |  3 +++
>   net/mac80211/mlme.c        | 12 ++++++++++++
>   net/mac80211/util.c        | 33 ++++++++++++++++++++++++++++++---
>   4 files changed, 56 insertions(+), 3 deletions(-)
> 
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index bd6912d0292b..0773c50fa182 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -6064,6 +6064,17 @@ void ieee80211_disconnect(struct ieee80211_vif *vif, bool reconnect);
>    */
>   void ieee80211_resume_disconnect(struct ieee80211_vif *vif);
>   
> +/**
> + * ieee80211_hw_restart_disconnect - disconnect from AP after
> + * hardware  restart

nits:
remove excess space in "hardware  restart"

"Do not leave a blank line between the function description and the 
arguments" per 
<https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation>

(I see that there is quite a mixture of compliant and non-compliant 
kernel-doc in this file)