Created attachment 252415 [details] core.txt from panic System is a T16-Gen1 with the Alder Lake wifi. When starting the network, it panics with: Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 12 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8359afd3 stack pointer = 0x28:0xfffffe00f1341c80 frame pointer = 0x28:0xfffffe00f1341d00 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (linuxkpi_short_wq_1) rdi: fffffe016695c4f8 rsi: fffffe00f1341c48 rdx: ffffffff8118971b rcx: 0000000000000000 r8: 0000000000000001 r9: ffffffffffffffff rax: 0000000000000000 rbx: fffffe0167886e80 rbp: fffffe00f1341d00 r10: 0000000000010000 r11: 0000000000000001 r12: fffffe0167887478 r13: 0000000000000000 r14: fffffe016695c4c8 r15: fffff80003bec540 core.txt is attached. The backtrace shows the following items: iwl_mvm_bt_notif_iterator() at iwl_mvm_bt_notif_iterator+0xf3/frame 0xfffffe00f1341d00 linuxkpi_ieee80211_iterate_interfaces() at linuxkpi_ieee80211_iterate_interfaces+0x84/frame 0xfffffe00f1341d40 iwl_mvm_bt_coex_notif_handle() at iwl_mvm_bt_coex_notif_handle+0x7c/frame 0xfffffe00f1341da0 iwl_mvm_async_handlers_wk() at iwl_mvm_async_handlers_wk+0x110/frame 0xfffffe00f1341df0
For some analysis see: https://lists.freebsd.org/archives/freebsd-wireless/2024-July/002305.html
Has this been reproducible for you?
*** Bug 283399 has been marked as a duplicate of this bug. ***
There's another report in https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255934 attached to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280430 which should belong here.
Thank you. Anything I can do? A few extra notes: 1. I believe this started after the most recent intel wifi update. I have noticed an increase in hard freezes since then. They seem to happen at random times. Not too frequently, like maybe after 24+ hours of running. 2. I cannot confirm that this is the cause of (1), but it seems likely. I think I just got lucky that I happened to hit the crash this early.
(In reply to mmatalka from comment #5) Are you using BT with that machine or in the vicinity? It sounds like it is reproducible for you (even at random)? Would you be willing/able to further debug or run with debug a patch to get more info into the crashinfo?
Bluetooth drivers get loaded but do not work on this laptop (AX2000 or whatever the chipset is). The crash happens to me once every day or 2 so I'm happy to run anything you want. I am currently not exporting crash dumps anywhere so please let me know what I need to do. I compile 15.0-CURRENT from source already so I can apply and install a patch easily enough.
(In reply to mmatalka from comment #7) The question is not so much if the iwmbt or later bluetooth driver gets loaded but if any bluetooth is used around you (could be headphones to a phone, a keyboard to a desktop, or otherwise). I'll try to come up with some diagnostic patch based on a previous debugging session where Andrea had already provided some good insights and we thought it was due to a mentioned race in the iwlwifi code. Back then it was the only substantial report but it seems we have at least 3 now.
(In reply to Bjoern A. Zeeb from comment #8) Yes, there is definitely bluetooth going in in my general vicinity. Thank you.
I just had the same crash apparently and will upload my logs as well. It happened on 14.2-RELEASE. And yes, I do use Bluetooth and there are quite a few Bluetooth devices around. kgdb quickly reveals a NULL-pointer dereference (chanctx_conf->def.chan == NULL). But I will spare you the details since bz@freebsd.org did already guess it from the previous report. I will happily do some more debugging with my vmcore on your request. I am not really willing to share the vmcore file, though. I don't understand this code enough to see whether it is valid that this pointer can be NULL. At least it is checked in other functions like iwl_mvm_bt_coex_notif_handle(). So I would suggest to simply add another NULL-pointer check to the existing if-statement in iwl_mvm_bt_notif_per_link(). And I would add the same to iwl_get_coex_type() as well. On the other hand, this pointer becoming NULL might have a deeper meaning and point to another problem. But even then, it could make sense to add an assertion after fixing the underlying problem.
Created attachment 257016 [details] Crash dumps from 14.2-RELEASE Crash dumps without vmcore. Created on FreeBSD thinkpad-x270 14.2-RELEASE FreeBSD 14.2-RELEASE releng/14.2-n269506-c8918d6c7412 GENERIC amd64
Well actually, this might already give you some vital information, so here's the dump of chanctx_conf: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:405 #2 0xffffffff80b3d797 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:523 #3 0xffffffff80b3dc6e in vpanic (fmt=0xffffffff8117704f "%s", ap=ap@entry=0xfffffe00c2937ae0) at /usr/src/sys/kern/kern_shutdown.c:967 #4 0xffffffff80b3dac3 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:891 #5 0xffffffff81025a0b in trap_fatal (frame=0xfffffe00c2937bc0, eva=12) at /usr/src/sys/amd64/amd64/trap.c:952 #6 0xffffffff81025a56 in trap_pfault (frame=<unavailable>, usermode=false, signo=<optimized out>, ucode=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:760 #7 <signal handler called> #8 0xffffffff83c68076 in iwl_mvm_bt_notif_per_link (mvm=0xfffffe00f17eb508, vif=0xfffffe00f4c24e80, data=0xfffffe00c2937d40, link_id=0) at /usr/src/sys/contrib/dev/iwlwifi/mvm/coex.c:292 #9 iwl_mvm_bt_notif_iterator (_data=_data@entry=0xfffffe00c2937d40, mac=<optimized out>, vif=vif@entry=0xfffffe00f4c24e80) at /usr/src/sys/contrib/dev/iwlwifi/mvm/coex.c:442 #10 0xffffffff80da3234 in linuxkpi_ieee80211_iterate_interfaces (hw=<optimized out>, flags=flags@entry=(IEEE80211_IFACE_ITER_NORMAL | IEEE80211_IFACE_ITER_ACTIVE | IEEE80211_IFACE_ITER__ATOMIC), iterfunc=0xffffffff83c67fd0 <iwl_mvm_bt_notif_iterator>, arg=arg@entry=0xfffffe00c2937d40) at /usr/src/sys/compat/linuxkpi/common/src/linux_80211.c:4865 #11 0xffffffff83c6789c in ieee80211_iterate_active_interfaces_atomic (hw=0xfffffe00c2937d40, flags=(IEEE80211_IFACE_ITER_NORMAL | IEEE80211_IFACE_ITER_ACTIVE | IEEE80211_IFACE_ITER__ATOMIC), arg=0xfffffe00c2937d40, iterfunc=<optimized out>) at /usr/src/sys/compat/linuxkpi/common/include/net/mac80211.h:1468 #12 iwl_mvm_bt_coex_notif_handle (mvm=0xfffffe00f17eb508) at /usr/src/sys/contrib/dev/iwlwifi/mvm/coex.c:459 #13 0xffffffff83c7eb7b in iwl_mvm_async_handlers_wk (wk=<optimized out>) at /usr/src/sys/contrib/dev/iwlwifi/mvm/ops.c:1563 #14 0xffffffff80dc3064 in linux_work_fn (context=0xfffffe00f17eb588, pending=<optimized out>) at /usr/src/sys/compat/linuxkpi/common/src/linux_work.c:301 #15 0xffffffff80ba0d82 in taskqueue_run_locked (queue=queue@entry=0xfffff800048f3500) at /usr/src/sys/kern/subr_taskqueue.c:518 #16 0xffffffff80ba2002 in taskqueue_thread_loop (arg=arg@entry=0xfffff800048322c0) at /usr/src/sys/kern/subr_taskqueue.c:830 #17 0xffffffff80af760f in fork_exit (callout=0xffffffff80ba1f40 <taskqueue_thread_loop>, arg=0xfffff800048322c0, frame=0xfffffe00c2937f40) at /usr/src/sys/kern/kern_fork.c:1164 #18 <signal handler called> (kgdb) f 8 #8 0xffffffff83c68076 in iwl_mvm_bt_notif_per_link (mvm=0xfffffe00f17eb508, vif=0xfffffe00f4c24e80, data=0xfffffe00c2937d40, link_id=0) at /usr/src/sys/contrib/dev/iwlwifi/mvm/coex.c:292 292 chanctx_conf->def.chan->band != NL80211_BAND_2GHZ)) { (kgdb) p chanctx_conf $1 = (struct ieee80211_chanctx_conf *) 0xfffff8004aeebd40 (kgdb) p *chanctx_conf $2 = {def = {chan = 0x0, width = NL80211_CHAN_WIDTH_20_NOHT, center_freq1 = 0, center_freq2 = 0, punctured = 0}, min_def = {chan = 0xfffff80048feb538, width = 82386608, center_freq1 = 4294965248, center_freq2 = 0, punctured = 0}, ap = {chan = 0x0, width = NL80211_CHAN_WIDTH_20_NOHT, center_freq1 = 0, center_freq2 = 0, punctured = 0}, rx_chains_dynamic = 1 '\001', rx_chains_static = 1 '\001', radar_enabled = false, drv_priv = 0xfffff8004aeebdc0 ""}
(In reply to Robin Haberkorn from comment #10) That crash just repeated - I have the same chanctx_conf->def.chan == NULL. Interestingly this happened the moment I power-cycled the wifi router, I was connected to. I will test whether this crash is reproducible.
(In reply to Robin Haberkorn from comment #13) I can reliably reproduce these crashes by power-cycling my router while there is some traffic on the network (e.g. a Youtube video playing). Having a bluetooth device paired is not a necessity to reproduce it. This is of course intolerable. I only recently switched from if_iwm to if_iwlwifi because of lags in delivery of bluetooth messages to userspace when having both wifi and bluetooth traffic at the same time. Perhaps I will try to patch my iwlwifi driver in the aforementioned way and see if it helps.
(In reply to Robin Haberkorn from comment #14) Hi Robin, thanks a lot for going the full way of finding a reproducer. That should also make it easier here to go and see about it if it works equally well in my setup. I've got this on the radar but there's only so much fish I can fry a days too ;-) If you find patching your iwlwifi with extra NULL pointer checks help it'll be good. It might still be that it'll just make it harder to his a race against something else but in the end everything will help at the moment. What would be interesting to know if you can panic this reliably and have the opportunity to further debug is what happens on the other CPUs at that time so we could identify the case we are racing against.
Created attachment 257106 [details] Proposed fix This patch just adds the NULL-pointer checks I discussed earlier. This does fix crashes, I could otherwise reproduce reliably.
Well except, that it doesn't. Because it's obviously a memory corruption issue: (kgdb) f 8 #8 iwl_mvm_bt_notif_per_link (mvm=0xfffffe00f1bb2508, vif=0xfffffe00f33cde80, data=0xfffffe00c294bd40, link_id=0) at /usr/src/sys/contrib/dev/iwlwifi/mvm/coex.c:292 292 chanctx_conf->def.chan->band != NL80211_BAND_2GHZ)) { (kgdb) f 8 #8 iwl_mvm_bt_notif_per_link (mvm=0xfffffe00f1bb2508, vif=0xfffffe00f33cde80, data=0xfffffe00c294bd40, link_id=0) at /usr/src/sys/contrib/dev/iwlwifi/mvm/coex.c:292 292 chanctx_conf->def.chan->band != NL80211_BAND_2GHZ)) { (kgdb) p chanctx_conf->def.chan $1 = (struct linuxkpi_ieee80211_channel *) 0x8086b85b (kgdb) p *chanctx_conf->def.chan Cannot access memory at address 0x8086b85b It's only sometimes resulting in unexpected NULL pointers. bz@FreeBSD.org, perhaps it would be worth to pull in upstream patches? The last update was in May of 2023. Actually, considering that this driver is supposed to be synced with the Linux kernel version, shouldn't that be the first thing we try?
(In reply to Robin Haberkorn from comment #17) I assume means you are on stable/14? main has newer versions than that and they along with a lot of other bits are on my MFC roadmap for the next week. I believe there is another problem with this looking at the code -- at least in main and that may be related to LinuxKPI bits not playing 100% by Linux rules. I've recently started to fix this for some other bits and will look into it for this one as well but I first need to flush a good part of my stack I am piling. Bare with me for a few days.
(In reply to Bjoern A. Zeeb from comment #18) I was on releng/14.2, which should be closest to the v14.2 release. But compared to stable/14, it's only missing the "script to extract firmware details". Compared to main, there are quite a few things missing, but as far as I can see, there still was no sync with the upstream sources.
Another report in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285729#c5
*** Bug 285961 has been marked as a duplicate of this bug. ***
Anyone seeing this, can you please try and apply https://reviews.freebsd.org/D49734 to your tree and report back if it helps? If you are not using arc you can download the entire diff on the right side "Download raw diff". It's a first start adjusting locking in LinuxKPI 802.11 and around the chanctx; there may be more work todo around "link_conf" which we don't fully support yet as we always only have one link.
currently no panic. got next error [1529] iwlwifi0: Queue 3 is stuck 230 234 [1529] iwlwifi0: Microcode SW error detected. Restarting 0x0. [1529] iwlwifi0: Start IWL Error Log Dump: [1529] iwlwifi0: Transport status: 0x0000004A, valid: 6 [1529] iwlwifi0: Loaded firmware version: 89.6b44fa0b.0 ma-b0-gf-a0-89.ucode [1529] iwlwifi0: 0x00000084 | NMI_INTERRUPT_UNKNOWN [1529] iwlwifi0: 0x008006F4 | trm_hw_status0 [1529] iwlwifi0: 0x00000000 | trm_hw_status1 [1529] iwlwifi0: 0x002DDF96 | branchlink2 [1529] iwlwifi0: 0x002D3A9A | interruptlink1 [1529] iwlwifi0: 0x002D3A9A | interruptlink2 [1529] iwlwifi0: 0x00008412 | data1 [1529] iwlwifi0: 0x01000000 | data2 [1529] iwlwifi0: 0x00000000 | data3 [1529] iwlwifi0: 0x6E803019 | beacon time [1529] iwlwifi0: 0x803FFE75 | tsf low [1529] iwlwifi0: 0x00000181 | tsf hi [1529] iwlwifi0: 0x00000000 | time gp1 [1529] iwlwifi0: 0x5A85F18D | time gp2 [1529] iwlwifi0: 0x00000001 | uCode revision type [1529] iwlwifi0: 0x00000059 | uCode version major [1529] iwlwifi0: 0x6B44FA0B | uCode version minor [1529] iwlwifi0: 0x00000441 | hw version [1529] iwlwifi0: 0x00C80002 | board version [1529] iwlwifi0: 0x0256001C | hcmd [1529] iwlwifi0: 0x80020000 | isr0 [1529] iwlwifi0: 0x00000000 | isr1 [1529] iwlwifi0: 0x48F00002 | isr2 [1529] iwlwifi0: 0x00C3008C | isr3 [1529] iwlwifi0: 0x00200000 | isr4 [1529] iwlwifi0: 0x03E5001C | last cmd Id [1529] iwlwifi0: 0x00008412 | wait_event [1529] iwlwifi0: 0x00000080 | l2p_control [1529] iwlwifi0: 0x00002020 | l2p_duration [1529] iwlwifi0: 0x0000003F | l2p_mhvalid [1529] iwlwifi0: 0x00001800 | l2p_addr_match [1529] iwlwifi0: 0x00000009 | lmpm_pmg_sel [1529] iwlwifi0: 0x00000000 | timestamp [1529] iwlwifi0: 0x00002884 | flow_handler [1529] iwlwifi0: Start IWL Error Log Dump: [1529] iwlwifi0: Transport status: 0x0000004A, valid: 7 [1529] iwlwifi0: 0x20000066 | NMI_INTERRUPT_HOST [1529] iwlwifi0: 0x00000000 | umac branchlink1 [1529] iwlwifi0: 0x8025FF6E | umac branchlink2 [1529] iwlwifi0: 0x80284D6A | umac interruptlink1 [1529] iwlwifi0: 0x80284D6A | umac interruptlink2 [1529] iwlwifi0: 0x01000000 | umac data1 [1529] iwlwifi0: 0x80284D6A | umac data2 [1529] iwlwifi0: 0x00000000 | umac data3 [1529] iwlwifi0: 0x00000059 | umac major [1529] iwlwifi0: 0x6B44FA0B | umac minor [1529] iwlwifi0: 0x5A85F18B | frame pointer [1529] iwlwifi0: 0xC0886260 | stack pointer [1529] iwlwifi0: 0x005A010C | last host cmd [1529] iwlwifi0: 0x00000400 | isr status reg [1529] iwlwifi0: IML/ROM dump: [1529] iwlwifi0: 0x00000B03 | IML/ROM error/state [1529] iwlwifi0: 0x00008305 | IML/ROM data1 [1529] iwlwifi0: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0 [1529] iwlwifi0: Fseq Registers: [1529] iwlwifi0: 0x60000100 | FSEQ_ERROR_CODE [1529] iwlwifi0: 0x80840003 | FSEQ_TOP_INIT_VERSION [1529] iwlwifi0: 0x003B0000 | FSEQ_CNVIO_INIT_VERSION [1529] iwlwifi0: 0x0000A652 | FSEQ_OTP_VERSION [1529] iwlwifi0: 0x00000003 | FSEQ_TOP_CONTENT_VERSION [1529] iwlwifi0: 0x4552414E | FSEQ_ALIVE_TOKEN [1529] iwlwifi0: 0x01080800 | FSEQ_CNVI_ID [1529] iwlwifi0: 0x00400410 | FSEQ_CNVR_ID [1529] iwlwifi0: 0x01080800 | CNVI_AUX_MISC_CHIP [1529] iwlwifi0: 0x00400410 | CNVR_AUX_MISC_CHIP [1529] iwlwifi0: 0x00009061 | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM [1529] iwlwifi0: 0x00000061 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR [1529] iwlwifi0: 0x003B0000 | FSEQ_PREV_CNVIO_INIT_VERSION [1529] iwlwifi0: 0x00840002 | FSEQ_WIFI_FSEQ_VERSION [1529] iwlwifi0: 0x00840002 | FSEQ_BT_FSEQ_VERSION [1529] iwlwifi0: 0x000000E6 | FSEQ_CLASS_TP_VERSION [1529] iwlwifi0: UMAC CURRENT PC: 0x80284828 [1529] iwlwifi0: LMAC1 CURRENT PC: 0xd0 [1529] iwlwifi0: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
devctl detach iwlwifi0 devctl attach '\_SB_.PC00.CNVW' restore wifi
(In reply to slw from comment #23) That's a scan error; indeed unrelated.
This is different bug?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=231168c7e77777f69a323bcd80a7956527d34548 commit 231168c7e77777f69a323bcd80a7956527d34548 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 16:35:20 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-11 21:25:56 +0000 LinuxKPI: 802.11: adjust locking around lkpi_remove_chanctx() With the adjusted locking as a first step and the single code path into lkpi_80211_mo_unassign_vif_chanctx() we also move the "setting chnactx to NULL" into the caller to simplify the code. Before we can adjust the other places touching vif->bss_conf.chanctx we need to adjust the overall locking in LinuxKPI 802.11. Sponsored by: The FreeBSD Foundation PR: 280546 MFC after: 3 days Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 sys/compat/linuxkpi/common/src/linux_80211.c | 39 +++++++++++++--------- sys/compat/linuxkpi/common/src/linux_80211.h | 2 +- .../linuxkpi/common/src/linux_80211_macops.c | 12 ++++--- 3 files changed, 32 insertions(+), 21 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=11604b2a1659fd6da9bbfdc6acf9758884cb2b36 commit 11604b2a1659fd6da9bbfdc6acf9758884cb2b36 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 00:56:36 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-11 21:17:55 +0000 LinuxKPI: 802.11: move chanctx_conf from vif to vif->bss_conf In preparations for MLD support chanctx_conf was moved from vif to the bss_conf as it will be per-link later. Follow accordingly. Sponsored by: The FreeBSD Foundation PR: 280546 MFC after: 3 days Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 sys/compat/linuxkpi/common/include/net/mac80211.h | 1 - sys/compat/linuxkpi/common/src/linux_80211.c | 20 ++++++++++---------- sys/compat/linuxkpi/common/src/linux_80211_macops.c | 2 +- 3 files changed, 11 insertions(+), 12 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a8a47a41775b0320606f90b3ac2048bc23494615 commit a8a47a41775b0320606f90b3ac2048bc23494615 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 23:05:43 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-11 21:26:05 +0000 LinuxKPI: 802.11: add a lchanctx list to lhw While we are currently only supporting a single VAP (vif) it is less of a trouble but in order to get locking and rcu accesses [from drivers] more right add a list for all chanctx_conf we have for one hw. Use that list in the iterator function to avoid having to lock the vif but not protecting the chanctx list (against a parallel removal) due to different locking. Sponsored by: The FreeBSD Foundation PR: 280546 MFC after: 3 days Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 sys/compat/linuxkpi/common/src/linux_80211.c | 39 ++++++++++++++++++---------- sys/compat/linuxkpi/common/src/linux_80211.h | 5 ++++ 2 files changed, 30 insertions(+), 14 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=50d826be664ef35065e8c4c4966252f2dfde9cb9 commit 50d826be664ef35065e8c4c4966252f2dfde9cb9 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-05 23:59:00 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-11 21:17:24 +0000 LinuxKPI: 802.11: reduce code duplication introducing lkpi_remove_chanctx() We have the same code three times, so factor it out into its own function to make it easier to maintain. Sponsored by: The FreeBSD Foundation PR: 280546 MFC after: 3 days Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 sys/compat/linuxkpi/common/include/net/mac80211.h | 2 +- sys/compat/linuxkpi/common/src/linux_80211.c | 80 ++++++++--------------- 2 files changed, 30 insertions(+), 52 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cd0fcf9f12114df542d4b080202abb1fe5f1aec8 commit cd0fcf9f12114df542d4b080202abb1fe5f1aec8 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 18:41:45 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-11 21:26:05 +0000 LinuxKPI: 802.11: switch to wiphy_lock Replace the LKPI_80211_LHW_LOCK (lhw->sx) with the wiphy lock (which is a Linux mutex, so also an sx lock). Apart from two places the change was mostly mechanically. Further remove the now recursive lock acquisitions. This lays the ground for us to use more Linux(KPI) 802.11 internal locking as well as more rcu equivalents, e.g., for the chanctx, and live better to the synchronisation expectations of the drivers. [I wish there would be more assertions in the drivers themselves, especially in the mac80211 ops and the iteration callbacks.] Sponsored by: The FreeBSD Foundation PR: 280546 MFC after: 3 days Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 sys/compat/linuxkpi/common/src/linux_80211.c | 122 ++++++++++++--------------- sys/compat/linuxkpi/common/src/linux_80211.h | 15 ---- 2 files changed, 56 insertions(+), 81 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=560708cbb0468bf1fd1834f4894a1326e88ff10e commit 560708cbb0468bf1fd1834f4894a1326e88ff10e Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 19:25:03 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-11 21:26:05 +0000 LinuxKPI: 802.11: adjust vif->bss_conf.chanctx_conf to rcu accessors Adjust the init and lkpi_sta_scan_to_auth() chanctx_conf accesses to use rcu functions as needed. linuxkpi_ieee80211_iterate_chan_contexts() which is ieee80211_iter_chan_contexts_atomic() needs further work to get rid of the vif locks by keeping all chanctx_conf on a list in lhw. This will be done in a follow-up commit. Sponsored by: The FreeBSD Foundation PR: 280546 MFC after: 3 days Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 sys/compat/linuxkpi/common/src/linux_80211.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=494894b11a9886ed974de79498ada136249cb930 commit 494894b11a9886ed974de79498ada136249cb930 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 00:56:36 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-18 14:36:00 +0000 LinuxKPI: 802.11: move chanctx_conf from vif to vif->bss_conf In preparations for MLD support chanctx_conf was moved from vif to the bss_conf as it will be per-link later. Follow accordingly. Sponsored by: The FreeBSD Foundation PR: 280546 Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 (cherry picked from commit 11604b2a1659fd6da9bbfdc6acf9758884cb2b36) sys/compat/linuxkpi/common/include/net/mac80211.h | 1 - sys/compat/linuxkpi/common/src/linux_80211.c | 20 ++++++++++---------- sys/compat/linuxkpi/common/src/linux_80211_macops.c | 2 +- 3 files changed, 11 insertions(+), 12 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=57764d222865c1182dd9bab55fda4e4c012ba56b commit 57764d222865c1182dd9bab55fda4e4c012ba56b Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-05 23:59:00 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-18 14:36:00 +0000 LinuxKPI: 802.11: reduce code duplication introducing lkpi_remove_chanctx() We have the same code three times, so factor it out into its own function to make it easier to maintain. Sponsored by: The FreeBSD Foundation PR: 280546 Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 (cherry picked from commit 50d826be664ef35065e8c4c4966252f2dfde9cb9) sys/compat/linuxkpi/common/include/net/mac80211.h | 2 +- sys/compat/linuxkpi/common/src/linux_80211.c | 80 ++++++++--------------- 2 files changed, 30 insertions(+), 52 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7614861463e6c26fdaaa79206b2bb0c79bb23683 commit 7614861463e6c26fdaaa79206b2bb0c79bb23683 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 16:35:20 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-18 14:36:01 +0000 LinuxKPI: 802.11: adjust locking around lkpi_remove_chanctx() With the adjusted locking as a first step and the single code path into lkpi_80211_mo_unassign_vif_chanctx() we also move the "setting chnactx to NULL" into the caller to simplify the code. Before we can adjust the other places touching vif->bss_conf.chanctx we need to adjust the overall locking in LinuxKPI 802.11. Sponsored by: The FreeBSD Foundation PR: 280546 Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 (cherry picked from commit 231168c7e77777f69a323bcd80a7956527d34548) sys/compat/linuxkpi/common/src/linux_80211.c | 39 +++++++++++++--------- sys/compat/linuxkpi/common/src/linux_80211.h | 2 +- .../linuxkpi/common/src/linux_80211_macops.c | 12 ++++--- 3 files changed, 32 insertions(+), 21 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3a35e07fa9309a357f9f7d25e86aba6f93c0af84 commit 3a35e07fa9309a357f9f7d25e86aba6f93c0af84 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 23:05:43 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-18 14:36:01 +0000 LinuxKPI: 802.11: add a lchanctx list to lhw While we are currently only supporting a single VAP (vif) it is less of a trouble but in order to get locking and rcu accesses [from drivers] more right add a list for all chanctx_conf we have for one hw. Use that list in the iterator function to avoid having to lock the vif but not protecting the chanctx list (against a parallel removal) due to different locking. Sponsored by: The FreeBSD Foundation PR: 280546 Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 (cherry picked from commit a8a47a41775b0320606f90b3ac2048bc23494615) sys/compat/linuxkpi/common/src/linux_80211.c | 39 ++++++++++++++++++---------- sys/compat/linuxkpi/common/src/linux_80211.h | 4 +++ 2 files changed, 29 insertions(+), 14 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=becb074fdefc40cff3365746a1036843e16c09d6 commit becb074fdefc40cff3365746a1036843e16c09d6 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 19:25:03 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-18 14:36:01 +0000 LinuxKPI: 802.11: adjust vif->bss_conf.chanctx_conf to rcu accessors Adjust the init and lkpi_sta_scan_to_auth() chanctx_conf accesses to use rcu functions as needed. linuxkpi_ieee80211_iterate_chan_contexts() which is ieee80211_iter_chan_contexts_atomic() needs further work to get rid of the vif locks by keeping all chanctx_conf on a list in lhw. This will be done in a follow-up commit. Sponsored by: The FreeBSD Foundation PR: 280546 Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 (cherry picked from commit 560708cbb0468bf1fd1834f4894a1326e88ff10e) sys/compat/linuxkpi/common/src/linux_80211.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7d57b5a339e34f4625739c6457c6c4f8369f87ae commit 7d57b5a339e34f4625739c6457c6c4f8369f87ae Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-04-08 18:41:45 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-04-18 14:36:01 +0000 LinuxKPI: 802.11: switch to wiphy_lock Replace the LKPI_80211_LHW_LOCK (lhw->sx) with the wiphy lock (which is a Linux mutex, so also an sx lock). Apart from two places the change was mostly mechanically. Further remove the now recursive lock acquisitions. This lays the ground for us to use more Linux(KPI) 802.11 internal locking as well as more rcu equivalents, e.g., for the chanctx, and live better to the synchronisation expectations of the drivers. [I wish there would be more assertions in the drivers themselves, especially in the mac80211 ops and the iteration callbacks.] Sponsored by: The FreeBSD Foundation PR: 280546 Tested by: Oleksandr Kryvulia (shuriku shurik.kiev.ua) Tested by: Oleg Nauman (oleg.nauman gmail.com) [rtw88] Differential Revision: https://reviews.freebsd.org/D49734 (cherry picked from commit cd0fcf9f12114df542d4b080202abb1fe5f1aec8) sys/compat/linuxkpi/common/src/linux_80211.c | 122 ++++++++++++--------------- sys/compat/linuxkpi/common/src/linux_80211.h | 14 --- 2 files changed, 56 insertions(+), 80 deletions(-)
The code changes are now also in stable/14. Thanks again for all the debugging and testing everyone had done before the changes were developed. I'll close the PR for now. If you can reproduce the problem after updating please re-open the PR.