Search Linux Wireless

Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux