On 09/09/2016 06:36 AM, Valo, Kalle wrote:
greearb@xxxxxxxxxxxxxxx writes:
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
I was seeing some spin-lock hangs in this area of the code,
and it seems more proper to do the rcu-read-lock outside of
the spin lock. I am not sure how much this matters, however.
Signed-off-by: Ben Greear <greearb@xxxxxxxxxxxxxxx>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 916119c..d96c06e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4307,8 +4307,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
int max;
int loop_max = 2000;
- spin_lock_bh(&ar->txqs_lock);
rcu_read_lock();
+ spin_lock_bh(&ar->txqs_lock);
last = list_last_entry(&ar->txqs, struct ath10k_txq, list);
while (!list_empty(&ar->txqs)) {
@@ -4342,8 +4342,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
break;
}
- rcu_read_unlock();
spin_unlock_bh(&ar->txqs_lock);
+ rcu_read_unlock();
I'm no RCU expert but this isn't making any sense. Maybe it changes
timings on your kernel so that it hides the real problem?
I'm not sure this fixed anything or not, it just seemed weird so I changed it.
I was hoping someone that understood rcu locking would comment...
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com