* [PATCH v6.1] wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()
@ 2022-11-02 11:48 ` Kalle Valo
0 siblings, 0 replies; 4+ messages in thread
From: Kalle Valo @ 2022-11-02 11:48 UTC (permalink / raw)
To: ath11k; +Cc: linux-wireless
From: Wen Gong <quic_wgong@quicinc.com>
(cherry picked from commit d99884ad9e3673a12879bc2830f6e5a66cccbd78 in ath-next
as users are seeing this bug more now, also cc stable)
Running this test in a loop it is easy to reproduce an rtnl deadlock:
iw reg set FI
ifconfig wlan0 down
What happens is that thread A (workqueue) tries to update the regulatory:
try to acquire the rtnl_lock of ar->regd_update_work
rtnl_lock+0x17/0x20
ath11k_regd_update+0x15a/0x260 [ath11k]
ath11k_regd_update_work+0x15/0x20 [ath11k]
process_one_work+0x228/0x670
worker_thread+0x4d/0x440
kthread+0x16d/0x1b0
ret_from_fork+0x22/0x30
And thread B (ifconfig) tries to stop the interface:
try to cancel_work_sync(&ar->regd_update_work) in ath11k_mac_op_stop().
ifconfig 3109 [003] 2414.232506: probe:
ath11k_mac_op_stop: (ffffffffc14187a0)
drv_stop+0x30 ([mac80211])
ieee80211_do_stop+0x5d2 ([mac80211])
ieee80211_stop+0x3e ([mac80211])
__dev_close_many+0x9e ([kernel.kallsyms])
__dev_change_flags+0xbe ([kernel.kallsyms])
dev_change_flags+0x23 ([kernel.kallsyms])
devinet_ioctl+0x5e3 ([kernel.kallsyms])
inet_ioctl+0x197 ([kernel.kallsyms])
sock_do_ioctl+0x4d ([kernel.kallsyms])
sock_ioctl+0x264 ([kernel.kallsyms])
__x64_sys_ioctl+0x92 ([kernel.kallsyms])
do_syscall_64+0x3a ([kernel.kallsyms])
entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms])
__GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so)
The sequence of deadlock is:
1. Thread B calls rtnl_lock().
2. Thread A starts to run and calls rtnl_lock() from within
ath11k_regd_update_work(), then enters wait state because the lock is owned by
thread B.
3. Thread B continues to run and tries to call
cancel_work_sync(&ar->regd_update_work), but thread A is in
ath11k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync()
forever waits for ath11k_regd_update_work() to finish and we have a deadlock.
Fix this by switching from using regulatory_set_wiphy_regd_sync() to
regulatory_set_wiphy_regd(). Now cfg80211 will schedule another workqueue which
handles the locking on it's own. So the ath11k workqueue can simply exit without
taking any locks, avoiding the deadlock.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Cc: <stable@vger.kernel.org>
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
[kvalo: improve commit log]
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
---
drivers/net/wireless/ath/ath11k/reg.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/ath/ath11k/reg.c
index 7ee3ff69dfc8..6fae4e61ede7 100644
--- a/drivers/net/wireless/ath/ath11k/reg.c
+++ b/drivers/net/wireless/ath/ath11k/reg.c
@@ -287,11 +287,7 @@ int ath11k_regd_update(struct ath11k *ar)
goto err;
}
- rtnl_lock();
- wiphy_lock(ar->hw->wiphy);
- ret = regulatory_set_wiphy_regd_sync(ar->hw->wiphy, regd_copy);
- wiphy_unlock(ar->hw->wiphy);
- rtnl_unlock();
+ ret = regulatory_set_wiphy_regd(ar->hw->wiphy, regd_copy);
kfree(regd_copy);
base-commit: 30ac96f7cc973bb850c718c9bbe1fdcedfbe826b
--
2.30.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH v6.1] wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()
@ 2022-11-02 11:48 ` Kalle Valo
0 siblings, 0 replies; 4+ messages in thread
From: Kalle Valo @ 2022-11-02 11:48 UTC (permalink / raw)
To: ath11k; +Cc: linux-wireless
From: Wen Gong <quic_wgong@quicinc.com>
(cherry picked from commit d99884ad9e3673a12879bc2830f6e5a66cccbd78 in ath-next
as users are seeing this bug more now, also cc stable)
Running this test in a loop it is easy to reproduce an rtnl deadlock:
iw reg set FI
ifconfig wlan0 down
What happens is that thread A (workqueue) tries to update the regulatory:
try to acquire the rtnl_lock of ar->regd_update_work
rtnl_lock+0x17/0x20
ath11k_regd_update+0x15a/0x260 [ath11k]
ath11k_regd_update_work+0x15/0x20 [ath11k]
process_one_work+0x228/0x670
worker_thread+0x4d/0x440
kthread+0x16d/0x1b0
ret_from_fork+0x22/0x30
And thread B (ifconfig) tries to stop the interface:
try to cancel_work_sync(&ar->regd_update_work) in ath11k_mac_op_stop().
ifconfig 3109 [003] 2414.232506: probe:
ath11k_mac_op_stop: (ffffffffc14187a0)
drv_stop+0x30 ([mac80211])
ieee80211_do_stop+0x5d2 ([mac80211])
ieee80211_stop+0x3e ([mac80211])
__dev_close_many+0x9e ([kernel.kallsyms])
__dev_change_flags+0xbe ([kernel.kallsyms])
dev_change_flags+0x23 ([kernel.kallsyms])
devinet_ioctl+0x5e3 ([kernel.kallsyms])
inet_ioctl+0x197 ([kernel.kallsyms])
sock_do_ioctl+0x4d ([kernel.kallsyms])
sock_ioctl+0x264 ([kernel.kallsyms])
__x64_sys_ioctl+0x92 ([kernel.kallsyms])
do_syscall_64+0x3a ([kernel.kallsyms])
entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms])
__GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so)
The sequence of deadlock is:
1. Thread B calls rtnl_lock().
2. Thread A starts to run and calls rtnl_lock() from within
ath11k_regd_update_work(), then enters wait state because the lock is owned by
thread B.
3. Thread B continues to run and tries to call
cancel_work_sync(&ar->regd_update_work), but thread A is in
ath11k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync()
forever waits for ath11k_regd_update_work() to finish and we have a deadlock.
Fix this by switching from using regulatory_set_wiphy_regd_sync() to
regulatory_set_wiphy_regd(). Now cfg80211 will schedule another workqueue which
handles the locking on it's own. So the ath11k workqueue can simply exit without
taking any locks, avoiding the deadlock.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Cc: <stable@vger.kernel.org>
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
[kvalo: improve commit log]
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
---
drivers/net/wireless/ath/ath11k/reg.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/ath/ath11k/reg.c
index 7ee3ff69dfc8..6fae4e61ede7 100644
--- a/drivers/net/wireless/ath/ath11k/reg.c
+++ b/drivers/net/wireless/ath/ath11k/reg.c
@@ -287,11 +287,7 @@ int ath11k_regd_update(struct ath11k *ar)
goto err;
}
- rtnl_lock();
- wiphy_lock(ar->hw->wiphy);
- ret = regulatory_set_wiphy_regd_sync(ar->hw->wiphy, regd_copy);
- wiphy_unlock(ar->hw->wiphy);
- rtnl_unlock();
+ ret = regulatory_set_wiphy_regd(ar->hw->wiphy, regd_copy);
kfree(regd_copy);
base-commit: 30ac96f7cc973bb850c718c9bbe1fdcedfbe826b
--
2.30.2
--
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v6.1] wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()
2022-11-02 11:48 ` Kalle Valo
@ 2022-11-02 17:22 ` Kalle Valo
-1 siblings, 0 replies; 4+ messages in thread
From: Kalle Valo @ 2022-11-02 17:22 UTC (permalink / raw)
To: ath11k; +Cc: linux-wireless
Kalle Valo <kvalo@kernel.org> writes:
> From: Wen Gong <quic_wgong@quicinc.com>
>
> (cherry picked from commit d99884ad9e3673a12879bc2830f6e5a66cccbd78 in ath-next
> as users are seeing this bug more now, also cc stable)
>
> Running this test in a loop it is easy to reproduce an rtnl deadlock:
>
> iw reg set FI
> ifconfig wlan0 down
>
> What happens is that thread A (workqueue) tries to update the regulatory:
>
> try to acquire the rtnl_lock of ar->regd_update_work
>
> rtnl_lock+0x17/0x20
> ath11k_regd_update+0x15a/0x260 [ath11k]
> ath11k_regd_update_work+0x15/0x20 [ath11k]
> process_one_work+0x228/0x670
> worker_thread+0x4d/0x440
> kthread+0x16d/0x1b0
> ret_from_fork+0x22/0x30
>
> And thread B (ifconfig) tries to stop the interface:
>
> try to cancel_work_sync(&ar->regd_update_work) in ath11k_mac_op_stop().
> ifconfig 3109 [003] 2414.232506: probe:
>
> ath11k_mac_op_stop: (ffffffffc14187a0)
> drv_stop+0x30 ([mac80211])
> ieee80211_do_stop+0x5d2 ([mac80211])
> ieee80211_stop+0x3e ([mac80211])
> __dev_close_many+0x9e ([kernel.kallsyms])
> __dev_change_flags+0xbe ([kernel.kallsyms])
> dev_change_flags+0x23 ([kernel.kallsyms])
> devinet_ioctl+0x5e3 ([kernel.kallsyms])
> inet_ioctl+0x197 ([kernel.kallsyms])
> sock_do_ioctl+0x4d ([kernel.kallsyms])
> sock_ioctl+0x264 ([kernel.kallsyms])
> __x64_sys_ioctl+0x92 ([kernel.kallsyms])
> do_syscall_64+0x3a ([kernel.kallsyms])
> entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms])
> __GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so)
>
> The sequence of deadlock is:
>
> 1. Thread B calls rtnl_lock().
>
> 2. Thread A starts to run and calls rtnl_lock() from within
> ath11k_regd_update_work(), then enters wait state because the lock is owned by
> thread B.
>
> 3. Thread B continues to run and tries to call
> cancel_work_sync(&ar->regd_update_work), but thread A is in
> ath11k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync()
> forever waits for ath11k_regd_update_work() to finish and we have a deadlock.
>
> Fix this by switching from using regulatory_set_wiphy_regd_sync() to
> regulatory_set_wiphy_regd(). Now cfg80211 will schedule another workqueue which
> handles the locking on it's own. So the ath11k workqueue can simply exit without
> taking any locks, avoiding the deadlock.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
> [kvalo: improve commit log]
> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Manually applied to ath-current branch of ath.git.
f45cb6b29cd3 wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v6.1] wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()
@ 2022-11-02 17:22 ` Kalle Valo
0 siblings, 0 replies; 4+ messages in thread
From: Kalle Valo @ 2022-11-02 17:22 UTC (permalink / raw)
To: ath11k; +Cc: linux-wireless
Kalle Valo <kvalo@kernel.org> writes:
> From: Wen Gong <quic_wgong@quicinc.com>
>
> (cherry picked from commit d99884ad9e3673a12879bc2830f6e5a66cccbd78 in ath-next
> as users are seeing this bug more now, also cc stable)
>
> Running this test in a loop it is easy to reproduce an rtnl deadlock:
>
> iw reg set FI
> ifconfig wlan0 down
>
> What happens is that thread A (workqueue) tries to update the regulatory:
>
> try to acquire the rtnl_lock of ar->regd_update_work
>
> rtnl_lock+0x17/0x20
> ath11k_regd_update+0x15a/0x260 [ath11k]
> ath11k_regd_update_work+0x15/0x20 [ath11k]
> process_one_work+0x228/0x670
> worker_thread+0x4d/0x440
> kthread+0x16d/0x1b0
> ret_from_fork+0x22/0x30
>
> And thread B (ifconfig) tries to stop the interface:
>
> try to cancel_work_sync(&ar->regd_update_work) in ath11k_mac_op_stop().
> ifconfig 3109 [003] 2414.232506: probe:
>
> ath11k_mac_op_stop: (ffffffffc14187a0)
> drv_stop+0x30 ([mac80211])
> ieee80211_do_stop+0x5d2 ([mac80211])
> ieee80211_stop+0x3e ([mac80211])
> __dev_close_many+0x9e ([kernel.kallsyms])
> __dev_change_flags+0xbe ([kernel.kallsyms])
> dev_change_flags+0x23 ([kernel.kallsyms])
> devinet_ioctl+0x5e3 ([kernel.kallsyms])
> inet_ioctl+0x197 ([kernel.kallsyms])
> sock_do_ioctl+0x4d ([kernel.kallsyms])
> sock_ioctl+0x264 ([kernel.kallsyms])
> __x64_sys_ioctl+0x92 ([kernel.kallsyms])
> do_syscall_64+0x3a ([kernel.kallsyms])
> entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms])
> __GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so)
>
> The sequence of deadlock is:
>
> 1. Thread B calls rtnl_lock().
>
> 2. Thread A starts to run and calls rtnl_lock() from within
> ath11k_regd_update_work(), then enters wait state because the lock is owned by
> thread B.
>
> 3. Thread B continues to run and tries to call
> cancel_work_sync(&ar->regd_update_work), but thread A is in
> ath11k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync()
> forever waits for ath11k_regd_update_work() to finish and we have a deadlock.
>
> Fix this by switching from using regulatory_set_wiphy_regd_sync() to
> regulatory_set_wiphy_regd(). Now cfg80211 will schedule another workqueue which
> handles the locking on it's own. So the ath11k workqueue can simply exit without
> taking any locks, avoiding the deadlock.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
> [kvalo: improve commit log]
> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Manually applied to ath-current branch of ath.git.
f45cb6b29cd3 wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
--
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-11-02 17:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-02 11:48 [PATCH v6.1] wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update() Kalle Valo
2022-11-02 11:48 ` Kalle Valo
2022-11-02 17:22 ` Kalle Valo
2022-11-02 17:22 ` Kalle Valo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.