Hit this bug on testing LKPI_80211_HW_CRYPTO in my private bug. backtraces: [3.519235] wlan0: link state changed to UP [3.535842] iwlwifi0: _lkpi_iv_key_set_delete: set_key succeeded: keyidx 0 hw_key_idx 0 flags 0 [3.537429] uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held: [3.537952] exclusive sleep mutex iwlwifi0_node_l (iwlwifi0_node_l) r = 0 (0xfffffe00ab44a620) locked @ /usr/src/sys/net80211/ieee80211_node.c:2209 [3.538837] stack backtrace: [3.539105] #0 0xffffffff80bc9475 at witness_debugger+0x65 [3.539522] #1 0xffffffff80bca5d9 at witness_warn+0x3e9 [3.539932] #2 0xffffffff80eeb174 at uma_zalloc_debug+0x34 [3.540353] #3 0xffffffff80eeac87 at uma_zalloc_arg+0x27 [3.540735] #4 0xffffffff80b273fe at malloc+0x7e [3.541082] #5 0xffffffff80de2182 at _lkpi_iv_key_set_delete+0x42 [3.541539] #6 0xffffffff80cd2124 at _ieee80211_crypto_delkey+0x74 [3.542007] #7 0xffffffff80cd208e at ieee80211_crypto_delkey+0x1e [3.542457] #8 0xffffffff80cfcde9 at ieee80211_node_delucastkey+0x79 [3.542923] #9 0xffffffff80cef1ce at ieee80211_ioctl_delkey+0xfe [3.543362] #10 0xffffffff80cecd68 at ieee80211_ioctl_set80211+0x5d8 [3.543838] #11 0xffffffff80ceb915 at ieee80211_ioctl+0x305 [3.544246] #12 0xffffffff80c8987f at ifioctl+0x93f [3.544598] #13 0xffffffff80bcedb6 at kern_ioctl+0x286 [3.544968] #14 0xffffffff80bceac3 at sys_ioctl+0x143 [3.545361] #15 0xffffffff8105d473 at amd64_syscall+0x153 [3.545779] #16 0xffffffff8102f89b at fast_syscall_common+0xf8 [3.547182] Sleeping thread (tid 100151, pid 303) owns a non-sleepable lock [3.547623] KDB: stack backtrace of thread 100151: [3.548105] sched_switch() at sched_switch+0x5d9/frame 0xfffffe00641e96d0 [3.549142] mi_switch() at mi_switch+0x170/frame 0xfffffe00641e96f0 [3.550112] sleepq_switch() at sleepq_switch+0x104/frame 0xfffffe00641e9730 [3.551133] sleepq_timedwait() at sleepq_timedwait+0x4b/frame 0xfffffe00641e9770 [3.552266] linux_add_to_sleepqueue() at linux_add_to_sleepqueue+0x92/frame 0xfffffe00641e97c0 [3.553520] linux_wait_event_common() at linux_wait_event_common+0x142/frame 0xfffffe00641e9800 [3.554653] iwl_trans_txq_send_hcmd() at iwl_trans_txq_send_hcmd+0x1ba/frame 0xfffffe00641e9890 [3.555701] iwl_trans_send_cmd() at iwl_trans_send_cmd+0xce/frame 0xfffffe00641e98c0 [3.556667] iwl_mvm_send_cmd_pdu() at iwl_mvm_send_cmd_pdu+0x6d/frame 0xfffffe00641e9910 [3.557662] _iwl_mvm_sec_key_del() at _iwl_mvm_sec_key_del+0x24b/frame 0xfffffe00641e99b0 [3.558663] iwl_mvm_mac_set_key() at iwl_mvm_mac_set_key+0x6c/frame 0xfffffe00641e99f0 [3.559822] _lkpi_iv_key_set_delete() at _lkpi_iv_key_set_delete+0x1c8/frame 0xfffffe00641e9a50 [3.561067] _ieee80211_crypto_delkey() at _ieee80211_crypto_delkey+0x74/frame 0xfffffe00641e9a70 [3.562296] ieee80211_crypto_delkey() at ieee80211_crypto_delkey+0x1e/frame 0xfffffe00641e9a90 [3.563517] ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x79/frame 0xfffffe00641e9ae0 [3.564779] ieee80211_ioctl_delkey() at ieee80211_ioctl_delkey+0xfe/frame 0xfffffe00641e9b10 [3.565986] ieee80211_ioctl_set80211() at ieee80211_ioctl_set80211+0x5d8/frame 0xfffffe00641e9b80 [3.567226] ieee80211_ioctl() at ieee80211_ioctl+0x305/frame 0xfffffe00641e9be0 [3.568333] ifioctl() at ifioctl+0x93f/frame 0xfffffe00641e9cd0 [3.569311] kern_ioctl() at kern_ioctl+0x286/frame 0xfffffe00641e9d30 [3.570316] sys_ioctl() at sys_ioctl+0x143/frame 0xfffffe00641e9e00 [3.571427] amd64_syscall() at amd64_syscall+0x153/frame 0xfffffe00641e9f30 [3.572382] fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00641e9f30 [3.573154] --- syscall (54, FreeBSD ELF64, ioctl), rip = 0xf05bde0bafa, rsp = 0xf05b7fc6f68, rbp = 0xf05b7fc6fc0 --- [3.573950] panic: sleeping thread [3.574108] cpuid = 1 [3.574181] time = 1708099872 [3.574306] KDB: stack backtrace: [3.574569] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00641d5710 [3.575614] vpanic() at vpanic+0x135/frame 0xfffffe00641d5840 [3.576540] panic() at panic+0x43/frame 0xfffffe00641d58a0 [3.577462] propagate_priority() at propagate_priority+0x29f/frame 0xfffffe00641d58e0 [3.578579] turnstile_wait() at turnstile_wait+0x377/frame 0xfffffe00641d5930 [3.579614] __mtx_lock_sleep() at __mtx_lock_sleep+0x1dc/frame 0xfffffe00641d59c0 [3.580665] __mtx_lock_flags() at __mtx_lock_flags+0xe1/frame 0xfffffe00641d5a10 [3.581766] _ieee80211_free_node() at _ieee80211_free_node+0x34/frame 0xfffffe00641d5a50 [3.582946] ieee80211_tx_complete() at ieee80211_tx_complete+0xd5/frame 0xfffffe00641d5a80 [3.584164] linuxkpi_ieee80211_tx_status_ext() at linuxkpi_ieee80211_tx_status_ext+0x379/frame 0xfffffe00641d5b80 [3.585551] linuxkpi_ieee80211_tx_status() at linuxkpi_ieee80211_tx_status+0x45/frame 0xfffffe00641d5bd0 [3.586735] iwl_mvm_rx_tx_cmd() at iwl_mvm_rx_tx_cmd+0x3bc/frame 0xfffffe00641d5ca0 [3.587696] iwl_mvm_rx_common() at iwl_mvm_rx_common+0x1d6/frame 0xfffffe00641d5ce0 [3.588655] iwl_pcie_rx_handle() at iwl_pcie_rx_handle+0x43d/frame 0xfffffe00641d5de0 [3.589629] iwl_pcie_napi_poll_msix() at iwl_pcie_napi_poll_msix+0x2d/frame 0xfffffe00641d5e20 [3.590823] lkpi_napi_task() at lkpi_napi_task+0x1f/frame 0xfffffe00641d5e40 [3.591905] taskqueue_run_locked() at taskqueue_run_locked+0xab/frame 0xfffffe00641d5ec0 [3.593039] taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfffffe00641d5ef0 [3.594161] fork_exit() at fork_exit+0x82/frame 0xfffffe00641d5f30 [3.594987] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00641d5f30 [3.595697] --- trap 0, rip = 0, rsp = 0, rbp = 0 --- [3.595988] KDB: enter: panic
Standard problem with net80211 ic lock being held; cannot sleep; the MO down calls almost all need to unlock if locked and re-lock afterwards as most of them apparently can sleep on Linux. If you want to work on HW_CRYPTO do you want to add the multi-key-fields support to D43648?
(In reply to Bjoern A. Zeeb from comment #1) Yes, I want to work in HW_CRYPTO and initially want to solve this PR. But I am new to "multi-key-fields". What exactly do you mean by "add the multi-key-fields support to D43648"?
(In reply to Cheng Cui from comment #2) If you look in net80211 you'll see there is an array of keys on the VAP: ieee80211_var.h: struct ieee80211_key iv_nw_keys[IEEE80211_WEP_NKID]; We'll need something similar in LinuxKPI 802.11 code, not just one key as is currently implemented there, given we may have more. If you look at ifconfig [-v|-vk] wlan0 you'll see something like: deftxkey UNDEF AES-CCM 2:128-bit The number before the : is the keyindex (human readable so keyidx+1).
(In reply to Bjoern A. Zeeb from comment #3) Let me think about these multiple keys support. My initial thought is that I need to create a separate PR to track that work. But how can we coordinate/co-work on D43648? Do I need to add my change on top of D43648, and send the total diff back to you?
(In reply to Cheng Cui from comment #4) Or you update that review; Phabricator should allow you. Otherwise you just open a new one with all things in and I drop mine.
Closing this (along with the others) as they seem to be overcome by events. *** This bug has been marked as a duplicate of bug 277100 ***