commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
introduced deadlock while processing rx in order indication message
for qca6174 based devices. While merging replenish and txrx tasklets,
replenish task should be called out of htt rx ring locking since it
is also try to acquire the same lock.
Unfortunately this issue is not exposed by other solutions (qca988x,
qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174
based devices. This patch fixes
=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-wt-ath+ #1353 Tainted: G E
---------------------------------------------
swapper/3/0 is trying to acquire lock:
(&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>]
ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]
but task is already holding lock:
(&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&htt->rx_ring.lock)->rlock);
lock(&(&htt->rx_ring.lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by swapper/3/0:
#0: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
Reported-by: Mike Lothian <[email protected]>
Signed-off-by: Rajkumar Manoharan <[email protected]>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 3b35c7ab5680..80e645302b54 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1905,7 +1905,6 @@ static void ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
return;
}
}
- ath10k_htt_rx_msdu_buff_replenish(htt);
}
static void ath10k_htt_rx_tx_fetch_resp_id_confirm(struct ath10k *ar,
--
2.8.3
Rajkumar Manoharan <[email protected]> wrote:
> commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
> introduced deadlock while processing rx in order indication message
> for qca6174 based devices. While merging replenish and txrx tasklets,
> replenish task should be called out of htt rx ring locking since it
> is also try to acquire the same lock.
>
> Unfortunately this issue is not exposed by other solutions (qca988x,
> qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174
> based devices. This patch fixes
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 4.7.0-rc2-wt-ath+ #1353 Tainted: G E
> ---------------------------------------------
> swapper/3/0 is trying to acquire lock:
> (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>]
> ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]
>
> but task is already holding lock:
> (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
> ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(&(&htt->rx_ring.lock)->rlock);
> lock(&(&htt->rx_ring.lock)->rlock);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 1 lock held by swapper/3/0:
> #0: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
> ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
> Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
> Reported-by: Mike Lothian <[email protected]>
> Signed-off-by: Rajkumar Manoharan <[email protected]>
Thanks, 1 patch applied to ath-current branch of ath.git:
e50525bef593 ath10k: fix deadlock while processing rx_in_ord_ind
--
Sent by pwcli
https://patchwork.kernel.org/patch/9166323/