gree...@candelatech.com writes:
> From: Ben Greear <gree...@candelatech.com>
>
> 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 <gree...@candelatech.com>
> ---
> 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?
--
Kalle Valo
