netdev - Re: [PATCH v5.1-rc] iwlwifi: make locking in iwl_mvm_tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9b6f5c279e8aea8e6241d03b0b21de88ac49e8b2.camel@sipsolutions.net>
Date:   Tue, 01 Oct 2019 11:52:57 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
        Luca Coelho <luciano.coelho@...el.com>,
        Intel Linux Wireless <linuxwifi@...el.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCH v5.1-rc] iwlwifi: make locking in iwl_mvm_tx_mpdu()
 BH-safe

On Tue, 2019-10-01 at 11:46 +0200, Johannes Berg wrote:
> 
> ieee80211_wake_queues_by_reason() does
> spin_lock_irqsave()/spin_unlock_irqrestore() - why is that "{SOFTIRQ-ON-
> W} usage"?

scratch that - _ieee80211_wake_txqs() unlocks that again...

It does hold RCU critical section, but that's not the same as disabling
BHs.

I think we should do this perhaps - I think it'd be better to ensure
that the drivers' wake_tx_queue op is always called with softirqs
disabled, since that happens in almost all cases already ...


diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 051a02ddcb85..ad1e88958da2 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -273,9 +273,9 @@ static void __ieee80211_wake_txqs(struct ieee80211_sub_if_data *sdata, int ac)
 						&txqi->flags))
 				continue;
 
-			spin_unlock_bh(&fq->lock);
+			spin_unlock(&fq->lock);
 			drv_wake_tx_queue(local, txqi);
-			spin_lock_bh(&fq->lock);
+			spin_lock(&fq->lock);
 		}
 	}
 
Perhaps we could add some validation into drv_wake_tx_queue(), but I
didn't find the right thing to call right now ...


Toke, what do you think?

johannes