Created attachment 767273 [details] emerge --info Hi, after I updated my kernel I noticed that wpa_gui shows lots of notifications about disconnecting and connecting to WiFi, and there are lots of CTRL-EVENT-BEACON-LOSS in wpa_supplicant logs that looks like this: >Mar 17 18:01:20 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:21 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:22 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:23 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:24 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:25 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:26 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:27 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:28 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:29 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-BEACON-LOSS >Mar 17 18:01:29 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-DISCONNECTED bssid=[REDACTED] reason=4 locally_generated=1 >Mar 17 18:01:29 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD >Mar 17 18:01:30 lapek wpa_supplicant[1345]: wlan0: SME: Trying to authenticate with [REDACTED] (SSID='nierusz' freq=2447 MHz) >Mar 17 18:01:30 lapek wpa_supplicant[1345]: wlan0: Trying to associate with [REDACTED] (SSID='nierusz' freq=2447 MHz) >Mar 17 18:01:30 lapek wpa_supplicant[1345]: wlan0: Associated with [REDACTED] >Mar 17 18:01:30 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 >Mar 17 18:01:30 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=PL >Mar 17 18:01:30 lapek wpa_supplicant[1345]: wlan0: WPA: Key negotiation completed with [REDACTED] [PTK=CCMP GTK=CCMP] >Mar 17 18:01:30 lapek wpa_supplicant[1345]: wlan0: CTRL-EVENT-CONNECTED - Connection to [REDACTED] completed [id=0 id_str=] I bisected kernel and get this commit: >2c1f97af38be151527380796d31d3c9adb054bf9 is the first bad commit >commit 2c1f97af38be151527380796d31d3c9adb054bf9 >Author: Halil Pasic <pasic@linux.ibm.com> >Date: Sat Mar 5 18:07:14 2022 +0100 > > swiotlb: rework "fix info leak with DMA_FROM_DEVICE" > > commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream. > > Unfortunately, we ended up merging an old version of the patch "fix info > leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph > (the swiotlb maintainer), he asked me to create an incremental fix > (after I have pointed this out the mix up, and asked him for guidance). > So here we go. > > The main differences between what we got and what was agreed are: > * swiotlb_sync_single_for_device is also required to do an extra bounce > * We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters > * The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE > must take precedence over DMA_ATTR_SKIP_CPU_SYNC > > Thus this patch removes DMA_ATTR_OVERWRITE, and makes > swiotlb_sync_single_for_device() bounce unconditionally (that is, also > when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale > data from the swiotlb buffer. > > Let me note, that if the size used with dma_sync_* API is less than the > size used with dma_[un]map_*, under certain circumstances we may still > end up with swiotlb not being transparent. In that sense, this is no > perfect fix either. > > To get this bullet proof, we would have to bounce the entire > mapping/bounce buffer. For that we would have to figure out the starting > address, and the size of the mapping in > swiotlb_sync_single_for_device(). While this does seem possible, there > seems to be no firm consensus on how things are supposed to work. > > Signed-off-by: Halil Pasic <pasic@linux.ibm.com> > Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE") > Cc: stable@vger.kernel.org > Reviewed-by: Christoph Hellwig <hch@lst.de> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Documentation/core-api/dma-attributes.rst | 8 -------- > include/linux/dma-mapping.h | 8 -------- > kernel/dma/swiotlb.c | 23 +++++++++++++++-------- > 3 files changed, 15 insertions(+), 24 deletions(-) lspci: >00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b) >00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) >00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b) >00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04) >00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04) >00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04) >00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4) >00:1c.2 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4) >00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4) >00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4) >00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04) >00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04) >00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04) >02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01) >02:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) >03:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01) >04:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 840M] (rev a2)
Created attachment 767274 [details] .config
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=45c6ca5497abf17af424683b4452f7d94f87bb71 commit 45c6ca5497abf17af424683b4452f7d94f87bb71 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2022-03-28 22:21:12 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2022-03-28 22:21:12 +0000 sys-kernel/gentoo-sources: Add revert for swiotlb patch Bug: https://bugs.gentoo.org/835513 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/gentoo-sources/Manifest | 3 +++ .../gentoo-sources/gentoo-sources-5.17.1-r1.ebuild | 28 ++++++++++++++++++++++ 2 files changed, 31 insertions(+)
This is now available in gentoo-sources-5.17.1-r1. This should be coming down the pipe from upstream for the next set of releases.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dbd8f4a8ca141f718a887623c7f64350b9041bd9 commit dbd8f4a8ca141f718a887623c7f64350b9041bd9 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2022-03-28 22:45:37 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2022-03-28 22:45:37 +0000 sys-kernel/gentoo-sources: Add revert for swiotlb patch to 5.16 Bug: https://bugs.gentoo.org/835513 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/gentoo-sources/Manifest | 3 +++ .../gentoo-sources-5.16.18-r1.ebuild | 28 ++++++++++++++++++++++ 2 files changed, 31 insertions(+)
Available in 5.16.18-r1
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35d503deb665bedebfee0c2ff865ec91ed21e72c commit 35d503deb665bedebfee0c2ff865ec91ed21e72c Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2022-03-28 23:03:54 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2022-03-28 23:03:54 +0000 sys-kernel/gentoo-sources: Add revert for swiotlb patch to 5.1r Bug: https://bugs.gentoo.org/835513 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/gentoo-sources/Manifest | 3 +++ .../gentoo-sources-5.15.32-r1.ebuild | 28 ++++++++++++++++++++++ 2 files changed, 31 insertions(+)
And finally gentoo-sources-5.15.32-r1
Resolving as fixed since we released gentoo-sources with the revert fix.