mbox series

[v3,0/3] wifi: rtw88: Three locking fixes for existing code

Message ID 20230108211324.442823-1-martin.blumenstingl@googlemail.com
Headers show
Series wifi: rtw88: Three locking fixes for existing code | expand

Message

Martin Blumenstingl Jan. 8, 2023, 9:13 p.m. UTC 
This series consists of three patches which are fixing existing
behavior (meaning: it either affects PCIe or USB or both) in the rtw88
driver.
We previously had discussed patches for these locking issues while
working on SDIO support, but the problem never ocurred while testing
USB cards. It turns out that these are still needed and I think that
they also fix the same problems for USB users (it's not clear how often
it happens there though) - and possibly even PCIe card users.

The issue fixed by the second and third patches have been spotted by a
user who tested rtw88 SDIO support. Everything is working fine for him
but there are warnings [1] and [2] in the kernel log stating "Voluntary
context switch within RCU read-side critical section!".

The solution in the third and fourth patch was actually suggested by
Ping-Ke in [3]. Thanks again!

These fixes are indepdent of my other series adding SDIO support to the
rtw88 driver, meaning they can be added to the wireless driver tree on
top of Linux 6.2-rc1 or linux-next.


Changes since v1 at [4]:
- Keep the u8 bitfields in patch 1 but split the res2 field into res2_1
  and res2_2 as suggested by Ping-Ke
- Added Ping-Ke's reviewed-by to patches 2-4 - thank you!
- Added a paragraph in the cover-letter to avoid confusion whether
  these patches depend on the rtw88 SDIO support series

Changes since v2 at [5]:
- Added Ping-Ke's Reviewed-by and Sascha's Tested-by (thanks to both of
  you!)
- Dropped patch 1/4 "rtw88: Add packed attribute to the eFuse structs"
  This requires more discussion. I'll send a separate patch for this.
- Updated cover letter title so it's clear that this is independent of
  SDIO support code


[0] https://lore.kernel.org/linux-wireless/695c976e02ed44a2b2345a3ceb226fc4@realtek.com/
[1] https://github.com/LibreELEC/LibreELEC.tv/pull/7301#issuecomment-1366421445
[2] https://github.com/LibreELEC/LibreELEC.tv/pull/7301#issuecomment-1366610249
[3] https://lore.kernel.org/lkml/e0aa1ba4336ab130712e1fcb425e6fd0adca4145.camel@realtek.com/
[4] https://lore.kernel.org/linux-wireless/20221228133547.633797-1-martin.blumenstingl@googlemail.com/
[5] https://lore.kernel.org/linux-wireless/20221229124845.1155429-1-martin.blumenstingl@googlemail.com/


Martin Blumenstingl (3):
  wifi: rtw88: Move register access from rtw_bf_assoc() outside the RCU
  wifi: rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter()
  wifi: rtw88: Use non-atomic sta iterator in rtw_ra_mask_info_update()

 drivers/net/wireless/realtek/rtw88/bf.c       | 13 +++++++------
 drivers/net/wireless/realtek/rtw88/mac80211.c |  4 +++-
 drivers/net/wireless/realtek/rtw88/main.c     |  6 ++++--
 3 files changed, 14 insertions(+), 9 deletions(-)

Comments

Martin Blumenstingl Jan. 10, 2023, 9:30 p.m. UTC | #1 
Hi Kalle,

On Sun, Jan 8, 2023 at 10:13 PM Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> This series consists of three patches which are fixing existing
> behavior (meaning: it either affects PCIe or USB or both) in the rtw88
> driver.
In reply to an earlier version of this series you wrote [0]:
> BTW wireless-next or wireless-testing are the preferred baselines for
> wireless patches. Of course you can use other trees if you really want,
> but please try to make sure they apply to wireless-next. Conflicts are
> always extra churn I would prefer to avoid.
Noted.
Additionally I just tested it and can confirm that these patches apply
fine (without any fuzz) on top of the wireless tree.


Best regards,
Martin


[0] https://lore.kernel.org/linux-wireless/87mt6qfvb1.fsf@kernel.org/