Linux wireless drivers development
 help / color / mirror / Atom feed
From: Luca Coelho <luca@coelho.fi>
To: kvalo@codeaurora.org
Cc: linux-wireless@vger.kernel.org,
	Sara Sharon <sara.sharon@intel.com>,
	Luca Coelho <luciano.coelho@intel.com>
Subject: [PATCH 02/20] iwlwifi: pcie: fix TX while flushing
Date: Fri,  8 Feb 2019 12:46:54 +0200	[thread overview]
Message-ID: <20190208104712.16210-3-luca@coelho.fi> (raw)
In-Reply-To: <20190208104712.16210-1-luca@coelho.fi>

From: Sara Sharon <sara.sharon@intel.com>

When flushing TX queues no new TX should go into the system.
However, in the following scenario we get TX:
1. Queues are stopped and there are packets in overflow queue
2. Station is removed and flush begins
3. Flush empties space, and reclaim path TXes SKB from overflow
   queue.

Note that the fact the queues are stopped during the process
doesn't matter - the packet will be TXed since the TX path
doesn't care if TX queues are stopped or not, just if there is
space in the queue, which there is, since we just freed a
packet.

A fix here is rather complicated, since the flow is very racy.

Change code not to warn if we are TXing from overflow TX.
In case there is TX from both overflow TX and TX path we will
miss a warning we optimally had, but we can live with that.

Make sure we don't return before overflow queue is empty, otherwise
we will think queues are empty, but they will be refilled, resulting
with assert.

Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Fixes: 3955525d5d17 ("iwlwifi: pcie: buffer packets to avoid overflowing Tx queues")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
 .../wireless/intel/iwlwifi/pcie/internal.h    |  2 ++
 .../net/wireless/intel/iwlwifi/pcie/trans.c   | 24 +++++++++++++++++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  | 10 ++++++++
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
index 9e1bcafad786..0ecd90d050e6 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -400,6 +400,8 @@ struct iwl_txq {
 	u32 id;
 	int low_mark;
 	int high_mark;
+
+	bool overflow_tx;
 };
 
 static inline dma_addr_t
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 6c30c88fc41e..4b31b0cdbd09 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -2240,6 +2240,7 @@ static int iwl_trans_pcie_wait_txq_empty(struct iwl_trans *trans, int txq_idx)
 	struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
 	struct iwl_txq *txq;
 	unsigned long now = jiffies;
+	bool overflow_tx;
 	u8 wr_ptr;
 
 	/* Make sure the NIC is still alive in the bus */
@@ -2251,18 +2252,37 @@ static int iwl_trans_pcie_wait_txq_empty(struct iwl_trans *trans, int txq_idx)
 
 	IWL_DEBUG_TX_QUEUES(trans, "Emptying queue %d...\n", txq_idx);
 	txq = trans_pcie->txq[txq_idx];
+
+	spin_lock_bh(&txq->lock);
+	overflow_tx = txq->overflow_tx ||
+		      !skb_queue_empty(&txq->overflow_q);
+	spin_unlock_bh(&txq->lock);
+
 	wr_ptr = READ_ONCE(txq->write_ptr);
 
-	while (txq->read_ptr != READ_ONCE(txq->write_ptr) &&
+	while ((txq->read_ptr != READ_ONCE(txq->write_ptr) ||
+		overflow_tx) &&
 	       !time_after(jiffies,
 			   now + msecs_to_jiffies(IWL_FLUSH_WAIT_MS))) {
 		u8 write_ptr = READ_ONCE(txq->write_ptr);
 
-		if (WARN_ONCE(wr_ptr != write_ptr,
+		/*
+		 * If write pointer moved during the wait, warn only
+		 * if the TX came from op mode. In case TX came from
+		 * trans layer (overflow TX) don't warn.
+		 */
+		if (WARN_ONCE(wr_ptr != write_ptr && !overflow_tx,
 			      "WR pointer moved while flushing %d -> %d\n",
 			      wr_ptr, write_ptr))
 			return -ETIMEDOUT;
+		wr_ptr = write_ptr;
+
 		usleep_range(1000, 2000);
+
+		spin_lock_bh(&txq->lock);
+		overflow_tx = txq->overflow_tx ||
+			      !skb_queue_empty(&txq->overflow_q);
+		spin_unlock_bh(&txq->lock);
 	}
 
 	if (txq->read_ptr != txq->write_ptr) {
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
index d8773e0a6062..9fbd37d23e85 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
@@ -1181,6 +1181,15 @@ void iwl_trans_pcie_reclaim(struct iwl_trans *trans, int txq_id, int ssn,
 		__skb_queue_head_init(&overflow_skbs);
 		skb_queue_splice_init(&txq->overflow_q, &overflow_skbs);
 
+		/*
+		 * We are going to transmit from the overflow queue.
+		 * Remember this state so that wait_for_txq_empty will know we
+		 * are adding more packets to the TFD queue. It cannot rely on
+		 * the state of &txq->overflow_q, as we just emptied it, but
+		 * haven't TXed the content yet.
+		 */
+		txq->overflow_tx = true;
+
 		/*
 		 * This is tricky: we are in reclaim path which is non
 		 * re-entrant, so noone will try to take the access the
@@ -1209,6 +1218,7 @@ void iwl_trans_pcie_reclaim(struct iwl_trans *trans, int txq_id, int ssn,
 			iwl_wake_queue(trans, txq);
 
 		spin_lock_bh(&txq->lock);
+		txq->overflow_tx = false;
 	}
 
 	if (txq->read_ptr == txq->write_ptr) {
-- 
2.20.1


  parent reply	other threads:[~2019-02-08 10:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08 10:46 [PATCH 00/20] iwlwifi: updates intended for v5.1 2019-02-08 Luca Coelho
2019-02-08 10:46 ` [PATCH 01/20] iwlwifi: bump FW API to 46 for 9000 and 22000 series Luca Coelho
2019-02-08 10:46 ` Luca Coelho [this message]
2019-02-08 10:46 ` [PATCH 03/20] iwlwifi: mvm: add support for 32kHz external clock indication Luca Coelho
2019-02-08 10:46 ` [PATCH 04/20] iwlwifi: dbg: temporarily skip periphery dump for AX210 devices Luca Coelho
2019-02-08 10:46 ` [PATCH 05/20] iwlwifi: align to new periphery address space for AX210 family Luca Coelho
2019-02-08 10:46 ` [PATCH 06/20] iwlwifi: add force NMI for AX210 devices Luca Coelho
2019-02-08 10:46 ` [PATCH 07/20] iwlwifi: mvm: add a debug_enable op Luca Coelho
2019-02-08 10:47 ` [PATCH 08/20] iwiwifi: mvm: Fix FW scan concurrency support assumptions Luca Coelho
2019-02-08 10:47 ` [PATCH 09/20] iwlwifi: mvm: add support for new FTM fw API Luca Coelho
2019-02-08 10:47 ` [PATCH 10/20] iwlwifi: mvm: fix HE radiotap data4 for HE-TB PPDUs Luca Coelho
2019-02-08 10:47 ` [PATCH 11/20] iwlwifi: mvm: add debug prints for FTM Luca Coelho
2019-02-12  7:56   ` [PATCH 11/20 v2] " Luca Coelho
2019-02-13  6:55     ` [PATCH 11/20 v3] " Luca Coelho
2019-02-08 10:47 ` [PATCH 12/20] iwlwifi: start using B-step for some 9000 devices Luca Coelho
2019-02-08 10:47 ` [PATCH 13/20] iwlwifi: properly use delay option in dump trigger flow Luca Coelho
2019-02-08 10:47 ` [PATCH 14/20] iwlwifi: dbg_ini: enable ignore consecutive trigger feature Luca Coelho
2019-02-08 10:47 ` [PATCH 15/20] iwlwifi: mvm: fix the spatial reuse parsing for HE_TRIG PPDUs Luca Coelho
2019-02-08 10:47 ` [PATCH 16/20] iwlwifi: dbg: buffer overflow in non_collect_ts_start array Luca Coelho
2019-02-08 10:47 ` [PATCH 17/20] iwlwifi: mvm: Don't warn on command failure during restart Luca Coelho
2019-02-08 10:47 ` [PATCH 18/20] iwlwifi: mvm: Do not return an error value on HW restart Luca Coelho
2019-02-08 10:47 ` [PATCH 19/20] iwlwifi: dbg_ini: add early and after alive apply points to unified images Luca Coelho
2019-02-08 10:47 ` [PATCH 20/20] iwlwifi: mvm: stop static queues correctly Luca Coelho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190208104712.16210-3-luca@coelho.fi \
    --to=luca@coelho.fi \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luciano.coelho@intel.com \
    --cc=sara.sharon@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox