From: Alexander Wetzel <alexander@wetzel-home.de> To: Denis Kenzior <denkenz@gmail.com>, Arend Van Spriel <arend.vanspriel@broadcom.com>, Kalle Valo <kvalo@codeaurora.org>, Maya Erez <merez@codeaurora.org> Cc: Ahmad Masri <amasri@codeaurora.org>, linux-wireless@vger.kernel.org, wil6210@qti.qualcomm.com Subject: Re: [PATCH 04/11] wil6210: fix PTK re-key race Date: Fri, 13 Sep 2019 22:48:13 +0200 Message-ID: <46f1141c-929c-9686-017d-fe4305d9c922@wetzel-home.de> (raw) In-Reply-To: <13f699ef-16c2-3ba7-79a0-0934f5e39368@gmail.com> Am 13.09.19 um 16:33 schrieb Denis Kenzior: > Hi Arend, Alexander, > >> Basically, we now have two bypass methods dealing with the >> same/similar issue: >> >> 1) bypass the QDISC. >> 2) bypass network stack entirely with CONTROL_PORT. > > It also raises the question in my mind as to why we have two ways of > doing the same thing? From the discussion so far it also sounds like > each requires somewhat different / special handling in the driver. > Wouldn't it make sense to deprecate one and encourage drivers to > implement the other? > My understanding is, that any control port frame must bypass any queues and just send out the frame directly, correct? Any packets send via it is directly jumping to the very front and is immediately send out. And that the intend of it is to replace the "old" path. So the best way forward here would be to 1) implement the patch here to work around the problem without control_port or the theoretical QDISC bypass 2) start implementing control port for the future. correct? > CONTROL_PORT was added specifically to take care of the re-keying races > and can be extended with additional attributes over time, as needed > (perhaps for extended key id, etc). Also note that in our testing > CONTROL_PORT is _way_ faster than PAE socket... > Extended Key ID is pretty robust when rekeying and the driver/card only has to take care to not mix KeyIDs within one A-MPDU. It's no problem encrypting eapol#4 with the new key. You can even encrypt it at the initial connect and it will work. Basically all races the "classical" rekey has to work around go away. For "normal" rekeys it's working pretty well with ath9k and iwlwifi even without control_port and just learned some weeks ago that QDISC could still cause issues... Alexander
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-08 8:32 [PATCH 00/11] wil6210 patches Maya Erez 2019-09-08 8:32 ` [PATCH 01/11] wil6210: add wil_netif_rx() helper function Maya Erez 2019-09-12 15:08 ` Kalle Valo 2019-09-08 8:32 ` [PATCH 02/11] wil6210: add support for pci linkdown recovery Maya Erez 2019-09-12 15:22 ` Kalle Valo 2019-09-08 8:32 ` [PATCH 03/11] wil6210: add debugfs to show PMC ring content Maya Erez 2019-09-08 8:32 ` [PATCH 04/11] wil6210: fix PTK re-key race Maya Erez 2019-09-10 13:23 ` Kalle Valo 2019-09-11 7:50 ` Arend Van Spriel 2019-09-11 18:32 ` Alexander Wetzel 2019-09-12 17:39 ` Denis Kenzior 2019-09-12 21:04 ` Alexander Wetzel 2019-09-13 8:04 ` Arend Van Spriel 2019-09-13 14:33 ` Denis Kenzior 2019-09-13 20:48 ` Alexander Wetzel [this message] 2019-09-17 15:32 ` Denis Kenzior 2019-09-13 18:43 ` Alexander Wetzel 2019-09-08 8:32 ` [PATCH 05/11] wil6210: make sure DR bit is read before rest of the status message Maya Erez 2019-09-08 8:32 ` [PATCH 06/11] wil6210: verify cid value is valid Maya Erez 2019-09-08 8:32 ` [PATCH 07/11] wil6210: properly initialize discovery_expired_work Maya Erez 2019-09-08 8:32 ` [PATCH 08/11] wil6210: report boottime_ns in scan results Maya Erez 2019-09-08 8:32 ` [PATCH 09/11] wil6210: use writel_relaxed in wil_debugfs_iomem_x32_set Maya Erez 2019-09-08 8:32 ` [PATCH 10/11] wil6210: fix RX short frame check Maya Erez 2019-09-08 8:32 ` [PATCH 11/11] wil6210: ignore reset errors for FW during probe Maya Erez
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=46f1141c-929c-9686-017d-fe4305d9c922@wetzel-home.de \ --to=alexander@wetzel-home.de \ --cc=amasri@codeaurora.org \ --cc=arend.vanspriel@broadcom.com \ --cc=denkenz@gmail.com \ --cc=kvalo@codeaurora.org \ --cc=linux-wireless@vger.kernel.org \ --cc=merez@codeaurora.org \ --cc=wil6210@qti.qualcomm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Wireless Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-wireless/0 linux-wireless/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-wireless linux-wireless/ https://lore.kernel.org/linux-wireless \ linux-wireless@vger.kernel.org public-inbox-index linux-wireless Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-wireless AGPL code for this site: git clone https://public-inbox.org/public-inbox.git