linux-stable.git/drivers/net/wireless/intel, branch v5.4.16

iwlwifi: mvm: fix potential SKB leak on TXQ TX

2020-01-29T15:45:30+00:00

commit df2378ab0f2a9dd4cf4501268af1902cc4ebacd8 upstream.

When we transmit after TXQ dequeue, we aren't paying attention to
the return value of the transmit functions, leading to a potential
SKB leak.

Refactor the code a bit (and rename ..._tx to ..._tx_sta) to check
for this happening.

Signed-off-by: Johannes Berg 
Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model")
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix SKB leak on invalid queue

2020-01-29T15:45:30+00:00

commit b9f726c94224e863d4d3458dfec2e7e1284a39ce upstream.

It used to be the case that if we got here, we wouldn't warn
but instead allocate the queue (DQA). With using the mac80211
TXQs model this changed, and we really have nothing to do with
the frame here anymore, hence the warning now.

However, clearly we missed in coding & review that this is now
a pure error path and leaks the SKB if we return 0 instead of
an indication that the SKB needs to be freed. Fix this.

Signed-off-by: Johannes Berg 
Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model")
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: don't send the IWL_MVM_RXQ_NSSN_SYNC notif to Rx queues

2020-01-29T15:45:26+00:00

commit d829229e35f302fd49c052b5c5906c90ecf9911d upstream.

The purpose of this was to keep all the queues updated with
the Rx sequence numbers because unlikely yet possible
situations where queues can't understand if a specific
packet needs to be dropped or not.

Unfortunately, it was reported that this caused issues in
our DMA engine. We don't fully understand how this is related,
but this is being currently debugged. For now, just don't send
this notification to the Rx queues. This de-facto reverts my
commit 3c514bf831ac12356b695ff054bef641b9e99593:

iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues

This issue was reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=204873
https://bugzilla.kernel.org/show_bug.cgi?id=205001
and others maybe.

Fixes: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues")
CC:  # 5.3+
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

Revert "iwlwifi: mvm: fix scan config command size"

2020-01-29T15:45:26+00:00

commit 205608749e1ef394f513888091e613c5bfccbcca upstream.

Since v5.4-rc1 was released, iwlwifi started throwing errors when scan
commands were sent to the firmware with certain devices (depending on
the OTP burned in the device, which contains the list of available
channels).  For instance:

iwlwifi 0000:00:14.3: FW error in SYNC CMD SCAN_CFG_CMD

This bug was reported in the ArchLinux bug tracker:
https://bugs.archlinux.org/task/64703

And also in a specific case in bugzilla, when the lar_disabled option
was set: https://bugzilla.kernel.org/show_bug.cgi?id=205193

Revert the commit that introduced this error, by using the number of
channels from the OTP instead of the number of channels that is
specified in the FW TLV that tells us how many channels it supports.

This reverts commit 06eb547c4ae4382e70d556ba213d13c95ca1801b.

Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Mehmet Akif Tasova 
[ Luca: reworded the commit message a bit. ]
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

net: Fix packet reordering caused by GRO and listified RX cooperation

2020-01-29T15:45:22+00:00

[ Upstream commit c80794323e82ac6ab45052ebba5757ce47b4b588 ]

Commit 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL
skbs") introduces batching of GRO_NORMAL packets in napi_frags_finish,
and commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in
napi_gro_receive()") adds the same to napi_skb_finish. However,
dev_gro_receive (that is called just before napi_{frags,skb}_finish) can
also pass skbs to the networking stack: e.g., when the GRO session is
flushed, napi_gro_complete is called, which passes pp directly to
netif_receive_skb_internal, skipping napi->rx_list. It means that the
packet stored in pp will be handled by the stack earlier than the
packets that arrived before, but are still waiting in napi->rx_list. It
leads to TCP reorderings that can be observed in the TCPOFOQueue counter
in netstat.

This commit fixes the reordering issue by making napi_gro_complete also
use napi->rx_list, so that all packets going through GRO will keep their
order. In order to keep napi_gro_flush working properly, gro_normal_list
calls are moved after the flush to clear napi->rx_list.

iwlwifi calls napi_gro_flush directly and does the same thing that is
done by gro_normal_list, so the same change is applied there:
napi_gro_flush is moved to be before the flush of napi->rx_list.

A few other drivers also use napi_gro_flush (brocade/bna/bnad.c,
cortina/gemini.c, hisilicon/hns3/hns3_enet.c). The first two also use
napi_complete_done afterwards, which performs the gro_normal_list flush,
so they are fine. The latter calls napi_gro_receive right after
napi_gro_flush, so it can end up with non-empty napi->rx_list anyway.

Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
Signed-off-by: Maxim Mikityanskiy 
Cc: Alexander Lobakin 
Cc: Edward Cree 
Acked-by: Alexander Lobakin 
Acked-by: Saeed Mahameed 
Acked-by: Edward Cree 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix support for single antenna diversity

2020-01-17T18:49:02+00:00

commit bb99ff9baa02beb9216c86678999342197c849cc upstream.

When the single antenna diversity support was sent upstream, only some
definitions were sent, due to a bad revert.

Fix this by adding the actual code.

Fixes: 5952e0ec3f05 ("iwlwifi: mvm: add support for single antenna diversity")
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: consider ieee80211 station max amsdu value

2020-01-17T18:49:01+00:00

commit ee4cce9b9d6421d037ffc002536b918fd7f4aff3 upstream.

debugfs amsdu_len sets only the max_amsdu_len for ieee80211 station
so take it into consideration while getting max amsdu

Fixes: af2984e9e625 ("iwlwifi: mvm: add a debugfs entry to set a fixed size AMSDU for all TX packets")
Signed-off-by: Mordechay Goodstein 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

Revert "iwlwifi: assign directly to iwl_trans->cfg in QuZ detection"

2020-01-04T18:18:35+00:00

commit db5cce1afc8d2475d2c1c37c2a8267dd0e151526 upstream.

This reverts commit 968dcfb4905245dc64d65312c0d17692fa087b99.

Both that commit and commit 809805a820c6445f7a701ded24fdc6bbc841d1e4
attempted to fix the same bug (dead assignments to the local variable
cfg), but they did so in incompatible ways. When they were both merged,
independently of each other, the combination actually caused the bug to
reappear, leading to a firmware crash on boot for some cards.

https://bugzilla.kernel.org/show_bug.cgi?id=205719

Signed-off-by: Anders Kaseorg 
Acked-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: move power gating workaround earlier in the flow

2019-12-31T15:46:35+00:00

commit 0df36b90c47d93295b7e393da2d961b2f3b6cde4 upstream.

We need to reset the NIC after setting the bits to enable power
gating and that cannot be done too late in the flow otherwise it
cleans other registers and things that were already configured,
causing initialization to fail.

In order to fix this, move the function to the common code in trans.c
so it can be called directly from there at an earlier point, just
after the reset we already do during initialization.

Fixes: 9a47cb988338 ("iwlwifi: pcie: add workaround for power gating in integrated 22000")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205719
Cc: stable@ver.kernel.org # 5.4+
Reported-by: Anders Kaseorg 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

net: wireless: intel: iwlwifi: fix GRO_NORMAL packet stalling

2019-12-31T15:45:49+00:00

[ Upstream commit b167191e2a851cb2e4c6ef8b91c83ff73ef41872 ]

Commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in
napi_gro_receive()") has applied batched GRO_NORMAL packets processing
to all napi_gro_receive() users, including mac80211-based drivers.

However, this change has led to a regression in iwlwifi driver [1][2] as
it is required for NAPI users to call napi_complete_done() or
napi_complete() and the end of every polling iteration, whilst iwlwifi
doesn't use NAPI scheduling at all and just calls napi_gro_flush().
In that particular case, packets which have not been already flushed
from napi->rx_list stall in it until at least next Rx cycle.

Fix this by adding a manual flushing of the list to iwlwifi driver right
before napi_gro_flush() call to mimic napi_complete() logics.

I prefer to open-code gro_normal_list() rather than exporting it for 2
reasons:
* to prevent from using it and napi_gro_flush() in any new drivers,
  as it is the *really* bad way to use NAPI that should be avoided;
* to keep gro_normal_list() static and don't lose any CC optimizations.

I also don't add the "Fixes:" tag as the mentioned commit was only a
trigger that only exposed an improper usage of NAPI in this particular
driver.

[1] https://lore.kernel.org/netdev/PSXP216MB04388962C411CD0B17A86F47804A0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM
[2] https://bugzilla.kernel.org/show_bug.cgi?id=205647

Signed-off-by: Alexander Lobakin 
Acked-by: Luca Coelho 
Reported-by: Nicholas Johnson 
Tested-by: Nicholas Johnson 
Reviewed-by: Edward Cree 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin