Re: [PATCH 0/5] iwlwifi: updates intended for v4.16 2017-12-23

[Luca Coelho]

Hi,

On Sun, 2018-01-14 at 12:26 +0200, Kalle Valo wrote:
> "Grumbach, Emmanuel"  writes:
> 
> > On Fri, 2018-01-12 at 13:31 +0200, Kalle Valo wrote:
> > > From: Luca Coelho 
> > > 
> > > > Luca Coelho (1):
> > > >   iwlwifi: mvm: check if mac80211_queue is valid in
> > > > iwl_mvm_disable_txq
> > > > 
> > > > Mordechay Goodstein (1):
> > > >   iwlwifi: set default timstamp marker cmd
> > > > 
> > > > Sara Sharon (3):
> > > >   iwlwifi: mvm: flip AMSDU addresses only for 9000 family
> > > >   iwlwifi: mvm: take RCU lock before dereferencing
> > > >   iwlwifi: mvm: move TSO segment to a separate function
> > > 
> > > Most likely the merge window starts in 9 days so I need to start
> > > getting patches ready. As Luca is away should I apply these
> > > patches
> > > directly to wireless-drivers-next?
> > > 
> > 
> > First let me thank you for tracking this. I don't see anything that
> > we
> > really need in 4.16 here. Besides Luca's UBSAN warning, all the
> > rest
> > is for a new device family which won't be supported in 4.16 anyway.
> > 
> > So I opt to wait for Luca here.
> 
> Ok, I'll wait for him then.

Sorry for coming back to this just now, but yeah, Emmanuel is right
because of the holidays and my vacations, this got delayed, so it can
go to 4.17.  I'll include this as part of my next -next pull request.

--
Cheers,
Luca.

Re: rtl8821ae keep alive not set, connection lost

[Pkshih]

On Fri, 2018-02-02 at 14:13 -0600, Larry Finger wrote:
> On 02/02/2018 01:50 AM, Pkshih wrote:
> > Hi James,
> > 
> > In my experiment, unaligned-word-access may get wrong values that
> > are different from the value by byte-access. Actually, it can simply
> > verified by using 'lspci' to check PCI configuration space.
> > 
> > DBI read 0x70f:
> > _rtl8821ae_dbi_read:1127 r8 0x34f = 0x0017
> > _rtl8821ae_dbi_read:1131 r8 0x350 = 0x000c
> > _rtl8821ae_dbi_read:1136 r16 0x350 = 0x
> > 
> > DBI read 0x719:
> > _rtl8821ae_dbi_read:1127 r8 0x34d = 0x
> > _rtl8821ae_dbi_read:1131 r8 0x34e = 0x0002
> > _rtl8821ae_dbi_read:1136 r16 0x34e = 0x0200
> > 
> > 
> > According to the wrong and original value of 0x70f is 0xff, I think
> > larger L1 latency 0x70f[5:3] may be helpful. Please help to try
> > below patch. If it works, quirk table won't be necessary.
> > 
> > PK
> > 
> > 
> > diff --git a/rtl8821ae/hw.c b/rtl8821ae/hw.c
> > index 7d43ba002..e53af06ed 100644
> > --- a/rtl8821ae/hw.c
> > +++ b/rtl8821ae/hw.c
> > @@ -1123,7 +1123,8 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv 
> > *rtlpriv, u16 addr)
> >     }
> >     if (0 == tmp) {
> >     read_addr = REG_DBI_RDATA + addr % 4;
> > -   ret = rtl_read_word(rtlpriv, read_addr);
> > +
> > +   ret = rtl_read_byte(rtlpriv, read_addr);
> >     }
> >     return ret;
> >   }
> > @@ -1165,7 +1166,7 @@ static void _rtl8821ae_enable_aspm_back_door(struct 
> > ieee80211_hw *hw)
> >     }
> >   
> >     tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);
> > -   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
> > +   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | 0x38);
> >   
> >     tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);
> >     _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));
> > 
> 
> 
> PK,
> 
> This patch works perfectly on my x86_64 system. With it, the interface 
> handled a 
> 10 million count flood ping with <1000 packets dropped. It has now been 
> running 
> for at least 11 hours. Good work.
> 
> Can you explain that magic 0x38? I'm quite sure that Kalle will not accept 
> the 
> patch as is. He already thinks that rtlwifi and friends already have too many 
> magic numbers.
> 
The magic 0x38 represents L1 latency 0x70f[5:3]=b'111, and I will add definition
or macro to describe
0x70f and move all ASPM code into pci.c, if the problem was
solved. Hence, rtl8723de and rtl8723be
will use the same values, too.

Could you also help to test L1 latency as recommended value b'100? 
(i.e. 0x20 instead)

Thanks
PK

Re: rtl8821ae keep alive not set, connection lost

[Larry Finger]

On 02/02/2018 01:50 AM, Pkshih wrote:


Hi James,

In my experiment, unaligned-word-access may get wrong values that
are different from the value by byte-access. Actually, it can simply
verified by using 'lspci' to check PCI configuration space.

DBI read 0x70f:
_rtl8821ae_dbi_read:1127 r8 0x34f = 0x0017
_rtl8821ae_dbi_read:1131 r8 0x350 = 0x000c
_rtl8821ae_dbi_read:1136 r16 0x350 = 0x

DBI read 0x719:
_rtl8821ae_dbi_read:1127 r8 0x34d = 0x
_rtl8821ae_dbi_read:1131 r8 0x34e = 0x0002
_rtl8821ae_dbi_read:1136 r16 0x34e = 0x0200


According to the wrong and original value of 0x70f is 0xff, I think
larger L1 latency 0x70f[5:3] may be helpful. Please help to try
below patch. If it works, quirk table won't be necessary.

PK


diff --git a/rtl8821ae/hw.c b/rtl8821ae/hw.c
index 7d43ba002..e53af06ed 100644
--- a/rtl8821ae/hw.c
+++ b/rtl8821ae/hw.c
@@ -1123,7 +1123,8 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
-   ret = rtl_read_word(rtlpriv, read_addr);
+
+   ret = rtl_read_byte(rtlpriv, read_addr);
}
return ret;
  }
@@ -1165,7 +1166,7 @@ static void _rtl8821ae_enable_aspm_back_door(struct 
ieee80211_hw *hw)
}
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);

-   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
+   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | 0x38);
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);

_rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));

PK,

One more question: Will we need to make the same change to rtl8723be and 
rtl8723de?

Larry

Re: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift

[Arend van Spriel]

On 2/2/2018 5:55 PM, dpr...@deepplum.com wrote:

I'm curious about the "WiFi Aware" initiative by the WiFi Alliance.

Does LEDE and/or Linux support this protocol? I know gSupplicant is potentially 
the way such things are supposed to work, at least according to its supporters.

The general NAN (Neighborhood-Aware-Networking) concept makes a lot of sense at 
one level, but as an Internet guy, it troubles me that they decided to split 
from the Internet and go a balkanized direction. To me, the neighborhood is 
interesting only as part of a larger Internet.

It also troubles me that WiFi Aware is a "certification program" rather than a 
real standard.


It troubles me that you are breaking into an email conversation with a 
topic that in my opinion is totally unrelated. Although probably not 
intended as such it seems rude. Just start your own conversation.


Regards,
Arend


-Original Message-
From: "Toke Høiland-Jørgensen" 
Sent: Friday, February 2, 2018 10:11am
To: make-wifi-f...@lists.bufferbloat.net, linux-wireless@vger.kernel.org
Cc: "Toke Høiland-Jørgensen" 
Subject: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift

Since we now have the convenient helper to do so, actually adjust the
TSQ pacing shift for packets going out over a WiFi interface. This
significantly improves throughput for locally-originated TCP
connections. The default pacing shift of 10 corresponds to ~1ms of
queued packet data. Adjusting this to a shift of 8 (i.e. ~4ms) improves
1-hop throughput for ath9k by a factor of 3, whereas increasing it more
has diminishing returns.

Achieved throughput for different values of sk_pacing_shift (average of
5 iterations of 10-sec netperf runs to a host on the other side of the
WiFi hop):

sk_pacing_shift 10:  43.21 Mbps (pre-patch)
sk_pacing_shift  9:  78.17 Mbps
sk_pacing_shift  8: 123.94 Mbps
sk_pacing_shift  7: 128.31 Mbps

Latency for competing flows increases from ~3 ms to ~10 ms with this
change. This is about the same magnitude of queueing latency induced by
flows that are not originated on the WiFi device itself (and so are not
limited by TSQ).

Signed-off-by: Toke Høiland-Jørgensen 
---
  net/mac80211/tx.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 25904af38839..69722504e3e1 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3574,6 +3574,14 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
if (!IS_ERR_OR_NULL(sta)) {
struct ieee80211_fast_tx *fast_tx;

+   /* We need a bit of data queued to build aggregates properly, so
+* instruct the TCP stack to allow more than a single ms of data
+* to be queued in the stack. The value is a bit-shift of 1
+* second, so 8 is ~4ms of queued data. Only affects local TCP
+* sockets.
+*/
+   sk_pacing_shift_update(skb->sk, 8);
+
fast_tx = rcu_dereference(sta->fast_tx);

if (fast_tx &&

Re: rtl8821ae keep alive not set, connection lost

[Larry Finger]

On 02/02/2018 01:50 AM, Pkshih wrote:

Hi James,

In my experiment, unaligned-word-access may get wrong values that
are different from the value by byte-access. Actually, it can simply
verified by using 'lspci' to check PCI configuration space.

DBI read 0x70f:
_rtl8821ae_dbi_read:1127 r8 0x34f = 0x0017
_rtl8821ae_dbi_read:1131 r8 0x350 = 0x000c
_rtl8821ae_dbi_read:1136 r16 0x350 = 0x

DBI read 0x719:
_rtl8821ae_dbi_read:1127 r8 0x34d = 0x
_rtl8821ae_dbi_read:1131 r8 0x34e = 0x0002
_rtl8821ae_dbi_read:1136 r16 0x34e = 0x0200


According to the wrong and original value of 0x70f is 0xff, I think
larger L1 latency 0x70f[5:3] may be helpful. Please help to try
below patch. If it works, quirk table won't be necessary.

PK


diff --git a/rtl8821ae/hw.c b/rtl8821ae/hw.c
index 7d43ba002..e53af06ed 100644
--- a/rtl8821ae/hw.c
+++ b/rtl8821ae/hw.c
@@ -1123,7 +1123,8 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
-   ret = rtl_read_word(rtlpriv, read_addr);
+
+   ret = rtl_read_byte(rtlpriv, read_addr);
}
return ret;
  }
@@ -1165,7 +1166,7 @@ static void _rtl8821ae_enable_aspm_back_door(struct 
ieee80211_hw *hw)
}
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);

-   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
+   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | 0x38);
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);

_rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));




PK,

This patch works perfectly on my x86_64 system. With it, the interface handled a 
10 million count flood ping with <1000 packets dropped. It has now been running 
for at least 11 hours. Good work.


Can you explain that magic 0x38? I'm quite sure that Kalle will not accept the 
patch as is. He already thinks that rtlwifi and friends already have too many 
magic numbers.


Larry

RE: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift

[dpr...@deepplum.com]

I'm curious about the "WiFi Aware" initiative by the WiFi Alliance.

Does LEDE and/or Linux support this protocol? I know gSupplicant is potentially 
the way such things are supposed to work, at least according to its supporters.

The general NAN (Neighborhood-Aware-Networking) concept makes a lot of sense at 
one level, but as an Internet guy, it troubles me that they decided to split 
from the Internet and go a balkanized direction. To me, the neighborhood is 
interesting only as part of a larger Internet.

It also troubles me that WiFi Aware is a "certification program" rather than a 
real standard.

-Original Message-
From: "Toke Høiland-Jørgensen" 
Sent: Friday, February 2, 2018 10:11am
To: make-wifi-f...@lists.bufferbloat.net, linux-wireless@vger.kernel.org
Cc: "Toke Høiland-Jørgensen" 
Subject: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift

Since we now have the convenient helper to do so, actually adjust the
TSQ pacing shift for packets going out over a WiFi interface. This
significantly improves throughput for locally-originated TCP
connections. The default pacing shift of 10 corresponds to ~1ms of
queued packet data. Adjusting this to a shift of 8 (i.e. ~4ms) improves
1-hop throughput for ath9k by a factor of 3, whereas increasing it more
has diminishing returns.

Achieved throughput for different values of sk_pacing_shift (average of
5 iterations of 10-sec netperf runs to a host on the other side of the
WiFi hop):

sk_pacing_shift 10:  43.21 Mbps (pre-patch)
sk_pacing_shift  9:  78.17 Mbps
sk_pacing_shift  8: 123.94 Mbps
sk_pacing_shift  7: 128.31 Mbps

Latency for competing flows increases from ~3 ms to ~10 ms with this
change. This is about the same magnitude of queueing latency induced by
flows that are not originated on the WiFi device itself (and so are not
limited by TSQ).

Signed-off-by: Toke Høiland-Jørgensen 
---
 net/mac80211/tx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 25904af38839..69722504e3e1 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3574,6 +3574,14 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
if (!IS_ERR_OR_NULL(sta)) {
struct ieee80211_fast_tx *fast_tx;
 
+   /* We need a bit of data queued to build aggregates properly, so
+* instruct the TCP stack to allow more than a single ms of data
+* to be queued in the stack. The value is a bit-shift of 1
+* second, so 8 is ~4ms of queued data. Only affects local TCP
+* sockets.
+*/
+   sk_pacing_shift_update(skb->sk, 8);
+
fast_tx = rcu_dereference(sta->fast_tx);
 
if (fast_tx &&
-- 
2.16.0

___
Make-wifi-fast mailing list
make-wifi-f...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast

[PATCH] mac80211: remove redundant initialization to pointer 'hdr'

[Colin King]

From: Colin Ian King 

The pointer hrd is being initialized with a value that is never read
and re-assigned a little later, hence the initialization is redundant
and can be removed.

Cleans up clang warning:
net/mac80211/tx.c:1924:24: warning: Value stored to 'hdr' during its
initialization is never read

Signed-off-by: Colin Ian King 
---
 net/mac80211/tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 25904af38839..5decd0fb247c 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1921,7 +1921,7 @@ void ieee80211_xmit(struct ieee80211_sub_if_data *sdata,
 {
struct ieee80211_local *local = sdata->local;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
-   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+   struct ieee80211_hdr *hdr;
int headroom;
bool may_encrypt;
 
-- 
2.15.1

Get Your Dream Car Now

[KOJO MOTORS]

---
千葉大学医学部学部学務係　学生生活担当
　　E-mail：sae5...@office.chiba-u.jp
　〒260-8670　千葉市中央区亥鼻1-8-1
   TEL：直通043(226)2011　内線5035/5036
   FAX：　　043(226)2502　内線5061
---

[PATCH] cfg80211: fix cfg80211_beacon_dup

[Arnd Bergmann]

gcc-8 warns about some obviously incorrect code:

net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as 
destination [-Werror=restrict]

>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.

Cc: sta...@vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon 
callbacks")
Signed-off-by: Arnd Bergmann 
---
 net/mac80211/cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 46028e12e216..f4195a0f0279 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2892,7 +2892,7 @@ cfg80211_beacon_dup(struct cfg80211_beacon_data *beacon)
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
-   beacon->probe_resp = pos;
+   new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
-- 
2.9.0

[PATCH] mac80211: Adjust TSQ pacing shift

[Toke Høiland-Jørgensen]

Since we now have the convenient helper to do so, actually adjust the
TSQ pacing shift for packets going out over a WiFi interface. This
significantly improves throughput for locally-originated TCP
connections. The default pacing shift of 10 corresponds to ~1ms of
queued packet data. Adjusting this to a shift of 8 (i.e. ~4ms) improves
1-hop throughput for ath9k by a factor of 3, whereas increasing it more
has diminishing returns.

Achieved throughput for different values of sk_pacing_shift (average of
5 iterations of 10-sec netperf runs to a host on the other side of the
WiFi hop):

sk_pacing_shift 10:  43.21 Mbps (pre-patch)
sk_pacing_shift  9:  78.17 Mbps
sk_pacing_shift  8: 123.94 Mbps
sk_pacing_shift  7: 128.31 Mbps

Latency for competing flows increases from ~3 ms to ~10 ms with this
change. This is about the same magnitude of queueing latency induced by
flows that are not originated on the WiFi device itself (and so are not
limited by TSQ).

Signed-off-by: Toke Høiland-Jørgensen 
---
 net/mac80211/tx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 25904af38839..69722504e3e1 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3574,6 +3574,14 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
if (!IS_ERR_OR_NULL(sta)) {
struct ieee80211_fast_tx *fast_tx;
 
+   /* We need a bit of data queued to build aggregates properly, so
+* instruct the TCP stack to allow more than a single ms of data
+* to be queued in the stack. The value is a bit-shift of 1
+* second, so 8 is ~4ms of queued data. Only affects local TCP
+* sockets.
+*/
+   sk_pacing_shift_update(skb->sk, 8);
+
fast_tx = rcu_dereference(sta->fast_tx);
 
if (fast_tx &&
-- 
2.16.0

[bug report] NFC: nci: Add HCI over NCI protocol support

[Dan Carpenter]

Hello Christophe Ricard,

The patch 11f54f228643: "NFC: nci: Add HCI over NCI protocol support"
from Feb 1, 2015, leads to the following static checker warning:

net/nfc/nci/hci.c:297 nci_hci_cmd_received()
error: buffer overflow 'ndev->hci_dev->pipes' 127 <= 127

net/nfc/nci/hci.c
   294  static void nci_hci_cmd_received(struct nci_dev *ndev, u8 pipe,
   295   u8 cmd, struct sk_buff *skb)
   296  {
   297  u8 gate = ndev->hci_dev->pipes[pipe].gate;
   
->pipes[] has 127 elements and "pipe" can go up to 127 so this might be
reading one element beyond the end of the array.

   298  u8 status = NCI_HCI_ANY_OK | ~NCI_HCI_FRAGMENT;
   299  u8 dest_gate, new_pipe;
   300  struct nci_hci_create_pipe_resp *create_info;
   301  struct nci_hci_delete_pipe_noti *delete_info;
   302  struct nci_hci_all_pipe_cleared_noti *cleared_info;
   303  
   304  pr_debug("from gate %x pipe %x cmd %x\n", gate, pipe, cmd);
   305  

"pipe" can come from two places but their both essentially the same:

net/nfc/nci/hci.c
   413  static void nci_hci_msg_rx_work(struct work_struct *work)
   414  {
   415  struct nci_hci_dev *hdev =
   416  container_of(work, struct nci_hci_dev, msg_rx_work);
   417  struct sk_buff *skb;
   418  struct nci_hcp_message *message;
   419  u8 pipe, type, instruction;
   420  
   421  while ((skb = skb_dequeue(>msg_rx_queue)) != NULL) {
   422  pipe = NCI_HCP_MSG_GET_PIPE(skb->data[0]);
^^
The NCI_HCP_MSG_GET_PIPE() macro looks like this:

#define NCI_HCP_MSG_GET_PIPE(header) (header & 0x7f)

   423  skb_pull(skb, NCI_HCI_HCP_PACKET_HEADER_LEN);
   424  message = (struct nci_hcp_message *)skb->data;
   425  type = NCI_HCP_MSG_GET_TYPE(message->header);
   426  instruction = NCI_HCP_MSG_GET_CMD(message->header);
   427  skb_pull(skb, NCI_HCI_HCP_MESSAGE_HEADER_LEN);
   428  
   429  nci_hci_hcp_message_rx(hdev->ndev, pipe,
   430 type, instruction, skb);
   431  }
   432  }

regards,
dan carpenter

Re: [PATCH] ath10k: Support mgt frame per-chain rssi

[Arend van Spriel]

On 2/2/2018 2:03 AM, gree...@candelatech.com wrote:

From: Ben Greear 

This provides per-chain rssh for management frames received


'rssh' should be 'rssi'.

Regards,
Arend


over wmi.

Signed-off-by: Ben Greear 
---
  drivers/net/wireless/ath/ath10k/wmi.c | 21 -
  drivers/net/wireless/ath/ath10k/wmi.h |  1 +
  2 files changed, 21 insertions(+), 1 deletion(-)

Re: lockdep warning in mac80211/tx.c, 4.13.16+ kernel, ath9k related

[Toke Høiland-Jørgensen]

Ben Greear  writes:

> On 02/01/2018 02:47 PM, Johannes Berg wrote:
>> On Thu, 2018-02-01 at 23:40 +0100, Johannes Berg wrote:
>>>
>>> The code does a plain rcu_dereference(), no locking other than
>>> rcu_read_lock() involved.
>>>
>>> On second thought though, I'm not convinced that your modifications
>>> caused the problem.
>>>
>>> Given your call stack, we'd expect rcu_read_lock() somewhere around
>>> ath_tid_dequeue (or its caller(s)), since ieee80211_tx_dequeue clearly
>>> requires it.
>>>
>>> Normally, ieee80211_tx_dequeue() is called from various places that
>>> probably come from mac80211 and already hold the rcu_read_lock(), e.g.
>>> the wake_tx_queue op.
>>>
>>> In this case, you're coming from drv_sta_state, so not sure why the
>>> driver thinks it's OK to call the dequeue there.
>>
>> Just to clarify - it could just be that in the "normal" case, when a
>> station dies, there's nothing on the queues - so the dequeue just
>> doesn't do anything and never goes into the code path where the
>> rcu_dereference() is, hence it might be a bug in mainline that just
>> never triggers in ordinary scenarios.
>
> It looks like the code in ath9k has not been changed in that area for
> some time.

Hmm, I think the issue here is that after the switch to mac80211 txqs,
the driver is now draining mac80211 queues, whereas before it was only
draining its own driver-internal queues (which are protected by the
ath_txq_lock() that ath_tx_node_cleanup() does grab). And when the
switch to the mac80211 queues happened, a call to rcu_read_lock() should
have been added. But, well, I had no idea this was needed until just
now, so obviously I didn't add that... :)

> Would adding rcu_read_lock in drv_sta_state() be a possibility?

Think it should probably just be added in ath_tx_node_cleanup()? Can
send a patch...

-Toke

[PATCH] ath9k: Protect queue draining by rcu_read_lock()

[Toke Høiland-Jørgensen]

When ath9k was switched over to use the mac80211 intermediate queues,
node cleanup now drains the mac80211 queues. However, this call path is
not protected by rcu_read_lock() as it was previously entirely internal
to the driver which uses its own locking.

This leads to a possible rcu_dereference() without holding
rcu_read_lock(); but only if a station is cleaned up while having
packets queued on the TXQ. Fix this by adding the rcu_read_lock() to the
caller in ath9k.

Fixes: 50f08edf9809 ("ath9k: Switch to using mac80211 intermediate software 
queues.")
Cc: sta...@vger.kernel.org
Reported-by: Ben Greear 
Signed-off-by: Toke Høiland-Jørgensen 
---
 drivers/net/wireless/ath/ath9k/xmit.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 396bf05c6bf6..d8b041f48ca8 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2892,6 +2892,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct 
ath_node *an)
struct ath_txq *txq;
int tidno;
 
+   rcu_read_lock();
+
for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
tid = ath_node_to_tid(an, tidno);
txq = tid->txq;
@@ -2909,6 +2911,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct 
ath_node *an)
if (!an->sta)
break; /* just one multicast ath_atx_tid */
}
+
+   rcu_read_unlock();
 }
 
 #ifdef CONFIG_ATH9K_TX99
-- 
2.16.0

[PATCH] nl80211: Fix external_auth check for offloaded authentication

[Jouni Malinen]

From: Srinivas Dasari 

Unfortunately removal of the ext_feature flag in the last revision of
the patch ended up negating the comparison and prevented the command
from being processed (either nl80211_external_auth() or
rdev_external_auth() returns -EOPNOTSUPP). Fix this by adding back the
lost '!'.

Fixes: 40cbfa90218b ("cfg80211/nl80211: Optional authentication offload to 
userspace")
Signed-off-by: Srinivas Dasari 
Signed-off-by: Jouni Malinen 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cc6ec5b..3b6dbc1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12486,7 +12486,7 @@ static int nl80211_external_auth(struct sk_buff *skb, 
struct genl_info *info)
struct net_device *dev = info->user_ptr[1];
struct cfg80211_external_auth_params params;
 
-   if (rdev->ops->external_auth)
+   if (!rdev->ops->external_auth)
return -EOPNOTSUPP;
 
if (!info->attrs[NL80211_ATTR_SSID])
-- 
2.7.4