pull request: iwlwifi 2016-02-25

pull request: iwlwifi 2016-02-25

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.5 still. Two small fixes. One of them has a really visible impact when we remove stations.
Let me know if you have issues! Thanks.

The following changes since commit 20aa99bbddae74bded68338f9ba200ccae02858b:

  iwlwifi: pcie: fix erroneous return value (2016-02-15 13:38:31 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2016-02-25

for you to fetch changes up to 905e36ae172c83a30894a3adefab7d4f850fcf54:

  iwlwifi: mvm: Fix paging memory leak (2016-02-23 21:51:30 +0200)

----------------------------------------------------------------
Two fixes for 4.5:
* We forgot to free the paging memory (Matti)
* Fix the frames in flight accounting (Liad)

----------------------------------------------------------------
Liad Kaufman (1):
      iwlwifi: mvm: inc pending frames counter also when txing non-sta

Matti Gottlieb (1):
      iwlwifi: mvm: Fix paging memory leak

 drivers/net/wireless/intel/iwlwifi/mvm/fw.c  | 4 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +++
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 2 ++
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c  | 9 +++++++++
 4 files changed, 17 insertions(+), 1 deletion(-)

[PATCH 1/2] iwlwifi: mvm: inc pending frames counter also when txing non-sta

[Emmanuel Grumbach]

From: Liad Kaufman <liad.kaufman@intel.com>

Until this patch, when TXing non-sta the pending_frames counter
wasn't increased, but it WAS decreased in
iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain
conditions. This in turn caused much trouble when we need to
remove the station since we won't be waiting forever until
pending_frames gets 0. In certain cases, we were exhausting
the station table even in BSS mode, because we had a lot of
stale stations.

Increase the counter also in iwl_mvm_tx_skb_non_sta() after a
successful TX to avoid this outcome.

CC: <stable@vger.kernel.org> [3.18+]
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 0914ec2..a040edc 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -423,6 +423,15 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb)
 		return -1;
 	}
 
+	/*
+	 * Increase the pending frames counter, so that later when a reply comes
+	 * in and the counter is decreased - we don't start getting negative
+	 * values.
+	 * Note that we don't need to make sure it isn't agg'd, since we're
+	 * TXing non-sta
+	 */
+	atomic_inc(&mvm->pending_frames[sta_id]);
+
 	return 0;
 }
 
-- 
2.5.0

[PATCH 2/2] iwlwifi: mvm: Fix paging memory leak

[Emmanuel Grumbach]

From: Matti Gottlieb <matti.gottlieb@intel.com>

If the opmode is stopped and started again we did not free
the paging buffers. Fix that.
In addition when freeing the firmware's paging download
buffer, set the pointer to NULL.

Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c  | 4 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +++
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 2 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 4ed5180..0ccc697 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -107,7 +107,7 @@ static int iwl_send_tx_ant_cfg(struct iwl_mvm *mvm, u8 valid_tx_ant)
 				    sizeof(tx_ant_cmd), &tx_ant_cmd);
 }
 
-static void iwl_free_fw_paging(struct iwl_mvm *mvm)
+void iwl_free_fw_paging(struct iwl_mvm *mvm)
 {
 	int i;
 
@@ -127,6 +127,8 @@ static void iwl_free_fw_paging(struct iwl_mvm *mvm)
 			     get_order(mvm->fw_paging_db[i].fw_paging_size));
 	}
 	kfree(mvm->trans->paging_download_buf);
+	mvm->trans->paging_download_buf = NULL;
+
 	memset(mvm->fw_paging_db, 0, sizeof(mvm->fw_paging_db));
 }
 
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 5f3ac8c..ff7c6df 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1225,6 +1225,9 @@ void iwl_mvm_rx_umac_scan_complete_notif(struct iwl_mvm *mvm,
 void iwl_mvm_rx_umac_scan_iter_complete_notif(struct iwl_mvm *mvm,
 					      struct iwl_rx_cmd_buffer *rxb);
 
+/* Paging */
+void iwl_free_fw_paging(struct iwl_mvm *mvm);
+
 /* MVM debugfs */
 #ifdef CONFIG_IWLWIFI_DEBUGFS
 int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct dentry *dbgfs_dir);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
index 89ea70d..e80be9a 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
@@ -684,6 +684,8 @@ static void iwl_op_mode_mvm_stop(struct iwl_op_mode *op_mode)
 	for (i = 0; i < NVM_MAX_NUM_SECTIONS; i++)
 		kfree(mvm->nvm_sections[i].data);
 
+	iwl_free_fw_paging(mvm);
+
 	iwl_mvm_tof_clean(mvm);
 
 	ieee80211_free_hw(mvm->hw);
-- 
2.5.0

Re: pull request: iwlwifi 2016-02-25

[Kalle Valo]

"Grumbach, Emmanuel" <emmanuel.grumbach@intel.com> writes:

> This is a pull request for 4.5 still. Two small fixes. One of them has a really visible impact when we remove stations.
> Let me know if you have issues! Thanks.
>
> The following changes since commit 20aa99bbddae74bded68338f9ba200ccae02858b:
>
>   iwlwifi: pcie: fix erroneous return value (2016-02-15 13:38:31 +0200)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2016-02-25

Pulled, thanks.

-- 
Kalle Valo

Re: [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak

[Kalle Valo]

Emmanuel Grumbach <emmanuel.grumbach@intel.com> writes:

> From: Matti Gottlieb <matti.gottlieb@intel.com>
>
> If the opmode is stopped and started again we did not free
> the paging buffers. Fix that.
> In addition when freeing the firmware's paging download
> buffer, set the pointer to NULL.
>
> Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Nitpicking while writing the pull request for Dave:

What does "opmode is stopped" mean? Important bug fixes should have a
clear bug description from user's point of view. Using driver internal
jargon is gibberish to most people.

I investigated this myself and apparently "opmode" is stopped when the
module is unloaded or the PCI device is removed. So just say that in the
commit log and everyone understand much better.

(No actions needed, just for future reference.)

-- 
Kalle Valo

Re: [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak

[Luca Coelho]

Hi Kalle,

On Fri, 2016-03-04 at 18:07 +0200, Kalle Valo wrote:
> Emmanuel Grumbach <emmanuel.grumbach@intel.com> writes:
> 
> > From: Matti Gottlieb <matti.gottlieb@intel.com>
> > 
> > If the opmode is stopped and started again we did not free
> > the paging buffers. Fix that.
> > In addition when freeing the firmware's paging download
> > buffer, set the pointer to NULL.
> > 
> > Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> 
> Nitpicking while writing the pull request for Dave:
> 
> What does "opmode is stopped" mean? Important bug fixes should have a
> clear bug description from user's point of view. Using driver internal
> jargon is gibberish to most people.

I agree that there could be a bit more high-level description here, but
I also think it's good to keep a bit more details about what is
happening internally, so that developers understand too. ;)

Do you think it would be acceptable to keep the commit log most as it
is, but start with something like "Some paging buffers were not freed
when the driver is restarted."? I don't mean to change this commit
itself, but just so that we know how to please you (and users) while
still keeping the details as part of the commit logs... ;)


> I investigated this myself and apparently "opmode" is stopped when the
> module is unloaded or the PCI device is removed. So just say that in the
> commit log and everyone understand much better.

Our driver is divided roughly into two layers: the bus layer (called
transport) and the protocol layer (called opmode).  The name comes from
the difference between the two opmodes that we currently have.  One
supports only a single operating channel (dvm) and the other supports
multiple operating channels (mvm).

Hope this clarifies a bit. :)

--
Cheers,
Luca.

Re: [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak

[Kalle Valo]

Luca Coelho <luca@coelho.fi> writes:

> On Fri, 2016-03-04 at 18:07 +0200, Kalle Valo wrote:
>> Emmanuel Grumbach <emmanuel.grumbach@intel.com> writes:
>> 
>> > From: Matti Gottlieb <matti.gottlieb@intel.com>
>> > 
>> > If the opmode is stopped and started again we did not free
>> > the paging buffers. Fix that.
>> > In addition when freeing the firmware's paging download
>> > buffer, set the pointer to NULL.
>> > 
>> > Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
>> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>> 
>> Nitpicking while writing the pull request for Dave:
>> 
>> What does "opmode is stopped" mean? Important bug fixes should have a
>> clear bug description from user's point of view. Using driver internal
>> jargon is gibberish to most people.
>
> I agree that there could be a bit more high-level description here, but
> I also think it's good to keep a bit more details about what is
> happening internally, so that developers understand too. ;)

Sure, feel free to write as much as you want and in such detail as you
think is necessary :) Just having a clear summary without internal
jargon helps people outside of iwlwifi.

BTW, the other iwlwifi fix had a bit similar problem:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=fb896c44f88a75843a072cd6961b1615732f7811

What does "non-sta" mean in this context? Is it the AP or what? Or
something not part of the current BSS? I guess I might find a definition
from the spec or from iwlwifi sources but I really should not be forced
to do that.

> Do you think it would be acceptable to keep the commit log most as it
> is, but start with something like "Some paging buffers were not freed
> when the driver is restarted."? I don't mean to change this commit
> itself, but just so that we know how to please you (and users) while
> still keeping the details as part of the commit logs... ;)

That sounds good to me. What I'm after is that someone like Dave or
Linus can understand from the commit log what kind of bug this patch is
fixing, without looking into source or checking mailing lists. This is
especially more important in the later stages of the cycle.

>> I investigated this myself and apparently "opmode" is stopped when the
>> module is unloaded or the PCI device is removed. So just say that in the
>> commit log and everyone understand much better.
>
> Our driver is divided roughly into two layers: the bus layer (called
> transport) and the protocol layer (called opmode).  The name comes from
> the difference between the two opmodes that we currently have.  One
> supports only a single operating channel (dvm) and the other supports
> multiple operating channels (mvm).
>
> Hope this clarifies a bit. :)

It did, thanks.

-- 
Kalle Valo

Re: [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak

[Grumbach, Emmanuel]

On 03/06/2016 02:04 PM, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
>> On Fri, 2016-03-04 at 18:07 +0200, Kalle Valo wrote:
>>> Emmanuel Grumbach <emmanuel.grumbach@intel.com> writes:
>>>
>>>> From: Matti Gottlieb <matti.gottlieb@intel.com>
>>>>
>>>> If the opmode is stopped and started again we did not free
>>>> the paging buffers. Fix that.
>>>> In addition when freeing the firmware's paging download
>>>> buffer, set the pointer to NULL.
>>>>
>>>> Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
>>>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>>>
>>> Nitpicking while writing the pull request for Dave:
>>>
>>> What does "opmode is stopped" mean? Important bug fixes should have a
>>> clear bug description from user's point of view. Using driver internal
>>> jargon is gibberish to most people.
>>
>> I agree that there could be a bit more high-level description here, but
>> I also think it's good to keep a bit more details about what is
>> happening internally, so that developers understand too. ;)
>
> Sure, feel free to write as much as you want and in such detail as you
> think is necessary :) Just having a clear summary without internal
> jargon helps people outside of iwlwifi.
>
> BTW, the other iwlwifi fix had a bit similar problem:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=fb896c44f88a75843a072cd6961b1615732f7811
>
> What does "non-sta" mean in this context? Is it the AP or what? Or
> something not part of the current BSS? I guess I might find a definition
> from the spec or from iwlwifi sources but I really should not be forced
> to do that.

non-sta in that context means an skb sent without a valid ieee80211_sta 
buffer. Which basically means that it is a non-data frame or a multicast 
frame.

>
>> Do you think it would be acceptable to keep the commit log most as it
>> is, but start with something like "Some paging buffers were not freed
>> when the driver is restarted."? I don't mean to change this commit
>> itself, but just so that we know how to please you (and users) while
>> still keeping the details as part of the commit logs... ;)
>
> That sounds good to me. What I'm after is that someone like Dave or
> Linus can understand from the commit log what kind of bug this patch is
> fixing, without looking into source or checking mailing lists. This is
> especially more important in the later stages of the cycle.
>
>>> I investigated this myself and apparently "opmode" is stopped when the
>>> module is unloaded or the PCI device is removed. So just say that in the
>>> commit log and everyone understand much better.
>>
>> Our driver is divided roughly into two layers: the bus layer (called
>> transport) and the protocol layer (called opmode).  The name comes from
>> the difference between the two opmodes that we currently have.  One
>> supports only a single operating channel (dvm) and the other supports
>> multiple operating channels (mvm).
>>
>> Hope this clarifies a bit. :)
>
> It did, thanks.
>