Differential D49791
LinucKPI: 802.11: further locking workarounds fro crypto updates Authored by bz on Apr 11 2025, 11:08 PM. Tags None Referenced Files
Details There are cases when net80211 calls into crypto updates with the Sponsored by: The FreeBSD Foundation
Diff Detail
Event Timeline
Comment Actions Hello Bjoern, looks like it works! I'm not seeing panic at shutdown anymore. Thank you! I applied your patch against 680d34896c But, at first boot with this patch I got this panic at system startup: > <118>Created wlan(4) interfaces: wlan0. > <6>lo0: link state changed to UP > <118>Starting wpa_supplicant. > <118>Starting dhclient. > <118>wlan0: no link ...... > <6>wlan0: link state changed to UP > <118> got link > <118>DHCPREQUEST on wlan0 to 255.255.255.255 port 67 > <6>wlan0: link state changed to DOWN > <118>DHCPREQUEST on wlan0 to 255.255.255.255 port 67 > <118>wlan0 link state up -> down > iwlwifi0: Not associated and the session protection is over already... > iwlwifi0: linuxkpi_ieee80211_connection_loss: vif 0xfffffe0115d5cec0 vap 0xfffffe0115d5c010 state AUTH > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff80cd64e0 > stack pointer = 0x28:0xfffffe01121409a8 > frame pointer = 0x28:0xfffffe0112140a30 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 389 (wpa_supplicant) > rdi: c0dedeadc0dedead rsi: fffffe011611e2a5 rdx: 0000000000000001 > rcx: 0000000000000011 r8: dedeadc0dedeadc0 r9: c0dedeadc0dedead > rax: fffffe011611e384 rbx: fffffe0115d5c010 rbp: fffffe0112140a30 > r10: c0dedeadc0dedead r11: 0000000000000001 r12: fffffe011611e068 > r13: fffffe011611e2a5 r14: fffffe0112621000 r15: 0000000000000001 > trap number = 9 > panic: general protection fault > cpuid = 0 > time = 1744471792 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0112140720 > vpanic() at vpanic+0x136/frame 0xfffffe0112140850 > panic() at panic+0x43/frame 0xfffffe01121408b0 > trap_fatal() at trap_fatal+0x68/frame 0xfffffe01121408d0 > calltrap() at calltrap+0x8/frame 0xfffffe01121408d0 > --- trap 0x9, rip = 0xffffffff80cd64e0, rsp = 0xfffffe01121409a8, rbp = 0xfffffe0112140a30 --- > ieee80211_chan2mode() at ieee80211_chan2mode/frame 0xfffffe0112140a30 > ieee80211_sta_join() at ieee80211_sta_join+0x256/frame 0xfffffe0112140a80 > ieee80211_ioctl_setmlme() at ieee80211_ioctl_setmlme+0xfc/frame 0xfffffe0112140b10 > ieee80211_ioctl_set80211() at ieee80211_ioctl_set80211+0x9ad/frame 0xfffffe0112140b80 > ieee80211_ioctl() at ieee80211_ioctl+0x2de/frame 0xfffffe0112140be0 > ifioctl() at ifioctl+0x973/frame 0xfffffe0112140ce0 > kern_ioctl() at kern_ioctl+0x286/frame 0xfffffe0112140d40 > sys_ioctl() at sys_ioctl+0x12f/frame 0xfffffe0112140e00 > amd64_syscall() at amd64_syscall+0x15a/frame 0xfffffe0112140f30 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0112140f30 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x60c96590b0a, rsp = 0x60c8f6dbfd8, rbp = 0x60c8f6dc040 --- > KDB: enter: panic > I never seen this again at future reboots, so not sure what it was. Comment Actions Thanks for testing! I'll apply it to the tree.
Can you file a PR for that Blocking PR 283171; I assume this isieee80211_sta_join() -> ieee80211_alloc_node() -> ieee80211_chan2mode() and ic->ic_curchan may not be set? If you can lookup ieee80211_sta_join+0x256 that would be helpful to add to the PR. | ||||||||||||||||||||||||||||||||||||||