Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 5月, 2015 2 次提交
    • M
      mac80211: fix AP_VLAN crypto tailroom calculation · f9dca80b
      由 Michal Kazior 提交于 
      Some splats I was seeing:

 (a) WARNING: CPU: 1 PID: 0 at /devel/src/linux/net/mac80211/wep.c:102 ieee80211_wep_add_iv
 (b) WARNING: CPU: 1 PID: 0 at /devel/src/linux/net/mac80211/wpa.c:73 ieee80211_tx_h_michael_mic_add
 (c) WARNING: CPU: 3 PID: 0 at /devel/src/linux/net/mac80211/wpa.c:433 ieee80211_crypto_ccmp_encrypt

I've seen (a) and (b) with ath9k hw crypto and (c)
with ath9k sw crypto. All of them were related to
insufficient skb tailroom and I was able to
trigger these with ping6 program.

AP_VLANs may inherit crypto keys from parent AP.
This wasn't considered and yielded problems in
some setups resulting in inability to transmit
data because mac80211 wouldn't resize skbs when
necessary and subsequently drop some packets due
to insufficient tailroom.

For efficiency purposes don't inspect both AP_VLAN
and AP sdata looking for tailroom counter. Instead
update AP_VLAN tailroom counters whenever their
master AP tailroom counter changes.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f9dca80b
    • J
      mac80211: don't split remain-on-channel for coalescing · 252ec2b3
      由 Johannes Berg 提交于 
      Due to remain-on-channel scheduling delays, when we split an ROC
while coalescing, we'll usually get a picture like this:

existing ROC:  |------------------|
current time:              ^
new ROC:                   |------|              |-------|

If the expected response frames are then transmitted by the peer
in the hole between the two fragments of the new ROC, we miss
them and the process (e.g. ANQP query) fails.

mac80211 expects that the window to miss something is small:

existing ROC:  |------------------|
new ROC:                   |------||-------|

but that's normally not the case.

To avoid this problem, coalesce only if the new ROC's duration
is <= the remaining time on the existing one:

existing ROC:  |------------------|
new ROC:                   |-----|

and never split a new one but schedule it afterwards instead:

existing ROC:  |------------------|
new ROC:                                       |-------------|

type=bugfix
bug=not-tracked
fixes=unknown
Reported-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: NEliadX Peller <eliad@wizery.com>
Reviewed-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Tested-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      252ec2b3
  3. 19 5月, 2015 1 次提交
  5. 11 5月, 2015 1 次提交
    • J
      mac80211: move WEP tailroom size check · 47b4e1fc
      由 Janusz Dziedzic 提交于 
      Remove checking tailroom when adding IV as it uses only
headroom, and move the check to the ICV generation that
actually needs the tailroom.

In other case I hit such warning and datapath don't work,
when testing:
- IBSS + WEP
- ath9k with hw crypt enabled
- IPv6 data (ping6)

WARNING: CPU: 3 PID: 13301 at net/mac80211/wep.c:102 ieee80211_wep_add_iv+0x129/0x190 [mac80211]()
[...]
Call Trace:
[<ffffffff817bf491>] dump_stack+0x45/0x57
[<ffffffff8107746a>] warn_slowpath_common+0x8a/0xc0
[<ffffffff8107755a>] warn_slowpath_null+0x1a/0x20
[<ffffffffc09ae109>] ieee80211_wep_add_iv+0x129/0x190 [mac80211]
[<ffffffffc09ae7ab>] ieee80211_crypto_wep_encrypt+0x6b/0xd0 [mac80211]
[<ffffffffc09d3fb1>] invoke_tx_handlers+0xc51/0xf30 [mac80211]
[...]

Cc: stable@vger.kernel.org
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      47b4e1fc
  7. 24 4月, 2015 1 次提交
  9. 23 4月, 2015 1 次提交
  11. 20 4月, 2015 1 次提交
  13. 08 4月, 2015 1 次提交
  15. 07 4月, 2015 1 次提交
  17. 02 4月, 2015 10 次提交
  19. 01 4月, 2015 4 次提交
    • J
      mac80211: fix RX A-MPDU session reorder timer deletion · 788211d8
      由 Johannes Berg 提交于 
      There's an issue with the way the RX A-MPDU reorder timer is
deleted that can cause a kernel crash like this:

 * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
 * station is destroyed
 * reorder timer fires before ieee80211_free_tid_rx() runs,
   accessing the station, thus potentially crashing due to
   the use-after-free

The station deletion is protected by synchronize_net(), but
that isn't enough -- ieee80211_free_tid_rx() need not have
run when that returns (it deletes the timer.) We could use
rcu_barrier() instead of synchronize_net(), but that's much
more expensive.

Instead, to fix this, add a field tracking that the session
is being deleted. In this case, the only re-arming of the
timer happens with the reorder spinlock held, so make that
code not rearm it if the session is being deleted and also
delete the timer after setting that field. This ensures the
timer cannot fire after ___ieee80211_stop_rx_ba_session()
returns, which fixes the problem.

Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      788211d8
    • T
      mac80211: enhance readability of Minstrel-HTs rc_stats output · 9c00bb72
      由 Thomas Huehn 提交于 
      This patch restructures the rc_stats debugfs table of Minstrel-HT in
order to achieve better human readability. A new layout of the
statistics and a new header is added. In addition to the old layout
there are two new columns of information added:
idx	- representing the rate index of each rate in mac80211 which
	  can be used to set specific rates as fixed rate via debugfs
airtime	- the tx-time in micro seconds that a 1200 Byte packet
	  takes to be transmitted over the air at the given rate

The old layout of rc_stats:

type           rate      tpt eprob *prob ret  *ok(*cum)        ok(      cum)
HT20/LGI       MCS0      5.6 100.0 100.0   1    0(   0)         1(        1)
HT20/LGI   B   MCS1     10.5 100.0 100.0   0    0(   0)         1(        1)
HT20/LGI  A    MCS2     14.8 100.0 100.0   0    0(   0)         1(        1)
...

is changed into this new layout:

            best   ________rate______    __statistics__    ________last_______    ______sum-of________
mode guard #  rate  [name   idx airtime]  [ ø(tp) ø(prob)]  [prob.|retry|suc|att]  [#success | #attempts]
HT20  LGI  1         MCS0     0    1480      0.0      0.0      0.0   1     0 0             0   0
HT20  LGI  1     B   MCS1     1     740     10.5    100.0    100.0   0     0 0             1   1
HT20  LGI  1    A    MCS2     2     496     14.8    100.0    100.0   0     0 0             1   1
...
Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: NStefan Venz <ikstream86@gmail.com>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9c00bb72
    • T
      mac80211: enhance readability of Minstrels rc_stats output · e161f7f6
      由 Thomas Huehn 提交于 
      This patch restructures the rc_stats debugfs table of Minstrel in
order to achieve better human readability. A new layout of the
statistics and a new header is added. In addition to the old layout
there are two new columns of information added:
idx	- representing the rate index of each rate in mac80211 which
	  can be used to set specific rates as fixed rate via debugfs
airtime - the tx-time in micro seconds that a 1200 Byte packet
	  takes to be transmitted over the air at the given rate

The old layout of rc_stats:

    rate      tpt  eprob *prob ret  *ok(*cum)        ok(      cum)
 DP 1          0.9  93.5 100.0   1    0(   0)         2(        2)
    2          0.4  40.0 100.0   0    0(   0)         4(        10)
    5.5        0.0   0.0   0.0   0    0(   0)         0(        0)
...

is changed into this new layout:

best   _______rate_____    __statistics__    ________last_______    ______sum-of________
rate  [name idx tx-time]  [ ø(tp) ø(prob)]  [prob.|retry|suc|att]  [#success | #attempts]
 DP   1     0     9738      0.9    93.5     100.0   1     1 1             2   2
      2     1     4922      0.4    40.0     100.0   1     0 0             4   10
      5.5   2     1858      0.0     0.0       0.0   2     0 0             0   0
...
Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: NStefan Venz <ikstream86@gmail.com>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e161f7f6
    • J
      mac80211: use rhashtable for station table · 7bedd0cf
      由 Johannes Berg 提交于 
      We currently have a hand-rolled table with 256 entries and are
using the last byte of the MAC address as the hash. This hash
is obviously very fast, but collisions are easily created and
we waste a lot of space in the common case of just connecting
as a client to an AP where we just have a single station. The
other common case of an AP is also suboptimal due to the size
of the hash table and the ease of causing collisions.

Convert all of this to use rhashtable with jhash, which gives
us the advantage of a far better hash function (with random
perturbation to avoid hash collision attacks) and of course
that the hash table grows and shrinks dynamically with chain
length, improving both cases above.

Use a specialised hash function (using jhash, but with fixed
length) to achieve better compiler optimisation as suggested
by Sergey Ryazanov.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7bedd0cf
  21. 30 3月, 2015 17 次提交