2019-09-13 05:53:44

by Lukas Redlinger

Subject: BUG: using smp_processor_id() in preemptible [00000000] code: wpa_supplicant

Hello,

on Arch Linux 5.2.11 with wpa_supplicant 2.8 / 2.9 our systems
increasingly show this issue:

[72770.969617] BUG: using smp_processor_id() in preemptible [00000000]
code: wpa_supplicant/16207
[72770.969638] caller is ieee80211_xmit_fast_finish+0x5a/0x1e0 [mac80211]
[72770.969640] CPU: 2 PID: 16207 Comm: wpa_supplicant Tainted: G
W 5.2.11-arch1-1-ARCH #1
[72770.969641] Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 02/20/2019
[72770.969642] Call Trace:
[72770.969647] dump_stack+0x5c/0x80
[72770.969661] debug_smp_processor_id+0xde/0xe0
[72770.969674] ieee80211_xmit_fast_finish+0x5a/0x1e0 [mac80211]
[72770.969687] ieee80211_tx_dequeue+0x472/0xb50 [mac80211]
[72770.969695] iwl_mvm_mac_itxq_xmit+0x6f/0x100 [iwlmvm]
[72770.969721] _ieee80211_wake_txqs+0x218/0x450 [mac80211]
[72770.969733] ieee80211_wake_queues_by_reason+0x7a/0xd0 [mac80211]
[72770.969745] ieee80211_set_disassoc+0x48d/0x5d0 [mac80211]
[72770.969760] ieee80211_mgd_deauth.cold+0x4a/0x3f4 [mac80211]
[72770.969797] cfg80211_mlme_deauth+0xc1/0x220 [cfg80211]
[72770.969809] nl80211_deauthenticate+0xd8/0x120 [cfg80211]
[72770.969813] genl_family_rcv_msg+0x1f3/0x470
[72770.969815] genl_rcv_msg+0x47/0x90
[72770.969818] ? __kmalloc_node_track_caller+0x1b7/0x2d0
[72770.969819] ? genl_family_rcv_msg+0x470/0x470
[72770.969820] netlink_rcv_skb+0x75/0x140
[72770.969822] genl_rcv+0x24/0x40
[72770.969823] netlink_unicast+0x177/0x1f0
[72770.969824] netlink_sendmsg+0x1fe/0x3c0
[72770.969827] sock_sendmsg+0x4f/0x60
[72770.969828] ___sys_sendmsg+0x304/0x370
[72770.969831] ? unix_ioctl+0x99/0x190
[72770.969834] __sys_sendmsg+0x81/0xd0
[72770.969850] do_syscall_64+0x5f/0x1d0
[72770.969851] ? prepare_exit_to_usermode+0x85/0xb0
[72770.969853] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[72770.969855] RIP: 0033:0x7f0bf1c83598
[72770.969857] Code: 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00
00 00 f3 0f 1e fa 48 8d 05 85 4c 0c 00 8b 00 85 c0 75 17 b8 2e 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28
89 54
[72770.969857] RSP: 002b:00007ffc3580a188 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[72770.969859] RAX: ffffffffffffffda RBX: 0000555f92d1e8c0 RCX: 00007f0bf1c83598
[72770.969859] RDX: 0000000000000000 RSI: 00007ffc3580a1c0 RDI: 0000000000000004
[72770.969860] RBP: 0000555f92da0bc0 R08: 0000000000000004 R09: 000000000000000d
[72770.969860] R10: 00007ffc3580a294 R11: 0000000000000246 R12: 0000555f92d1e7d0
[72770.969861] R13: 00007ffc3580a1c0 R14: 00007ffc3580a294 R15: 0000555f92de7c40

Somebody already filed a bug here:
https://bugzilla.kernel.org/show_bug.cgi?id=204127

Do you guys need any more information? I do have 12 systems at a
costumer alternating between
https://bugzilla.kernel.org/show_bug.cgi?id=204127 and
https://bugzilla.kernel.org/show_bug.cgi?id=203805 ;-) so I could
provide more logs if needed...

Thanks in advance!

2019-09-13 12:12:05

by Toke Høiland-Jørgensen

Subject: Re: BUG: using smp_processor_id() in preemptible [00000000] code: wpa_supplicant

Lukas Redlinger <[email protected]> writes:

> Hello,
>
> on Arch Linux 5.2.11 with wpa_supplicant 2.8 / 2.9 our systems
> increasingly show this issue:
>
> [72770.969617] BUG: using smp_processor_id() in preemptible [00000000]
> code: wpa_supplicant/16207
> [72770.969638] caller is ieee80211_xmit_fast_finish+0x5a/0x1e0 [mac80211]
> [72770.969640] CPU: 2 PID: 16207 Comm: wpa_supplicant Tainted: G
> W 5.2.11-arch1-1-ARCH #1
> [72770.969641] Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 02/20/2019
> [72770.969642] Call Trace:
> [72770.969647] dump_stack+0x5c/0x80
> [72770.969661] debug_smp_processor_id+0xde/0xe0
> [72770.969674] ieee80211_xmit_fast_finish+0x5a/0x1e0 [mac80211]
> [72770.969687] ieee80211_tx_dequeue+0x472/0xb50 [mac80211]
> [72770.969695] iwl_mvm_mac_itxq_xmit+0x6f/0x100 [iwlmvm]
> [72770.969721] _ieee80211_wake_txqs+0x218/0x450 [mac80211]
> [72770.969733] ieee80211_wake_queues_by_reason+0x7a/0xd0 [mac80211]
> [72770.969745] ieee80211_set_disassoc+0x48d/0x5d0 [mac80211]
> [72770.969760] ieee80211_mgd_deauth.cold+0x4a/0x3f4 [mac80211]
> [72770.969797] cfg80211_mlme_deauth+0xc1/0x220 [cfg80211]
> [72770.969809] nl80211_deauthenticate+0xd8/0x120 [cfg80211]
> [72770.969813] genl_family_rcv_msg+0x1f3/0x470
> [72770.969815] genl_rcv_msg+0x47/0x90
> [72770.969818] ? __kmalloc_node_track_caller+0x1b7/0x2d0
> [72770.969819] ? genl_family_rcv_msg+0x470/0x470
> [72770.969820] netlink_rcv_skb+0x75/0x140
> [72770.969822] genl_rcv+0x24/0x40
> [72770.969823] netlink_unicast+0x177/0x1f0
> [72770.969824] netlink_sendmsg+0x1fe/0x3c0
> [72770.969827] sock_sendmsg+0x4f/0x60
> [72770.969828] ___sys_sendmsg+0x304/0x370
> [72770.969831] ? unix_ioctl+0x99/0x190
> [72770.969834] __sys_sendmsg+0x81/0xd0
> [72770.969850] do_syscall_64+0x5f/0x1d0
> [72770.969851] ? prepare_exit_to_usermode+0x85/0xb0
> [72770.969853] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Hmm, ieee80211_set_disassoc() has a call to ieee80211_flush_queues();
but that only calls into the driver, it doesn't flush the TXQ. Maybe we
need to add that?

-Toke