1. 06 5月, 2011 1 次提交
  2. 29 4月, 2011 1 次提交
  3. 27 4月, 2011 1 次提交
    • R
      mac80211: Fix warnings due to -Wunused-but-set-variable · 0915cba3
      Rajkumar Manoharan 提交于
      These warnings are exposed by gcc 4.6.
      net/mac80211/sta_info.c: In function 'sta_info_cleanup_expire_buffered':
      net/mac80211/sta_info.c:590:32: warning: variable 'sdata' set but not used
      net/mac80211/ibss.c: In function 'ieee80211_rx_mgmt_auth_ibss':
      net/mac80211/ibss.c:43:34: warning: variable 'status_code' set but not used
      net/mac80211/work.c: In function 'ieee80211_send_assoc':
      net/mac80211/work.c:203:9: warning: variable 'len' set but not used
      net/mac80211/tx.c: In function '__ieee80211_parse_tx_radiotap':
      net/mac80211/tx.c:1039:35: warning: variable 'sband' set but not used
      net/mac80211/mesh.c: In function 'ieee80211_mesh_rx_queued_mgmt':
      net/mac80211/mesh.c:616:28: warning: variable 'ifmsh' set but not used
       ...
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0915cba3
  4. 13 4月, 2011 1 次提交
  5. 26 2月, 2011 1 次提交
    • J
      mac80211: make tx() operation return void · 7bb45683
      Johannes Berg 提交于
      The return value of the tx operation is commonly
      misused by drivers, leading to errors. All drivers
      will drop frames if they fail to TX the frame, and
      they must also properly manage the queues (if they
      didn't, mac80211 would already warn).
      
      Removing the ability for drivers to return a BUSY
      value also allows significant cleanups of the TX
      TX handling code in mac80211.
      
      Note that this also fixes a bug in ath9k_htc, the
      old "return -1" there was wrong.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k]
      Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00]
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi]
      Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx]
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bb45683
  6. 19 2月, 2011 1 次提交
  7. 08 2月, 2011 2 次提交
  8. 05 2月, 2011 2 次提交
    • B
      mac80211: Optimize scans on current operating channel. · b23b025f
      Ben Greear 提交于
      This should decrease un-necessary flushes, on/off channel work,
      and channel changes in cases where the only scanned channel is
      the current operating channel.
      
      * Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
        and is-scanning flags instead.
      
      * Add helper method to determine if we are currently configured
        for the operating channel.
      
      * Do no blindly go off/on channel in work.c  Instead, only call
        appropriate on/off code when we really need to change channels.
        Always enable offchannel-ps mode when starting work,
        and disable it when we are done.
      
      * Consolidate ieee80211_offchannel_stop_station and
        ieee80211_offchannel_stop_beaconing, call it
        ieee80211_offchannel_stop_vifs instead.
      
      * Accept non-beacon frames when scanning on operating channel.
      
      * Scan state machine optimized to minimize on/off channel
        transitions.  Also, when going on-channel, go ahead and
        re-enable beaconing.  We're going to be there for 200ms,
        so seems like some useful beaconing could happen.
        Always enable offchannel-ps mode when starting software
        scan, and disable it when we are done.
      
      * Grab local->mtx earlier in __ieee80211_scan_completed_finish
        so that we are protected when calling hw_config(), etc.
      
      * Pass probe-responses up the stack if scanning on local
        channel, so that mlme can take a look.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b23b025f
    • C
      mac80211: fix race between next beacon dtim and ieee80211_get_buffered_bc · 512119b3
      Christian Lamparter 提交于
      On review of 'zd1211rw: implement beacon fetching and handling
      ieee80211_get_buffered_bc()', Christian Lamparter noted that [1]:
      
         Since zd_beacon_done also uploads the next beacon so long in advance,
         there could be an equally long race between the outdated state of the
         next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
         which -in your case- was uploaded almost a beacon interval ago and
         the xmit of ieee80211_get_buffered_bc *now*.
      
         The dtim bc/mc bit might be not set, when a mc/bc arrived after the
         beacon was uploaded, but before the "beacon done event" from the
         hardware. So, dozing stations don't expect the broadcast traffic
         and of course, they might miss it completely.
      
         It's probably better to fix this in mac80211 (see the attached hack).
      
      [1] http://marc.info/?l=linux-wireless&m=129435041117256&w=2
      
      CC: Christian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      512119b3
  9. 04 2月, 2011 1 次提交
    • A
      mac80211: do not calc frame duration when using HW rate-control · 8fd369ee
      Arik Nemtsov 提交于
      When rate-control is performed in HW, we cannot calculate frame
      duration as we do not have the skb transmission rate in SW.
      
      ieee80211_tx_h_calculate_duration() should only be called when
      ieee80211_tx_h_rate_ctrl() has been called before to initialize data
      in skb->cb. This doesn't happen for drivers with HW rate-control.
      
      Fixes the following warning when operating in AP-mode
      in a driver with HW rate-control.
      
      WARNING: at net/mac80211/tx.c:57 ieee80211_duration+0x54/0x1d8 [mac80211]()
      Modules linked in: wl1271_sdio wl1271 firmware_class crc7 mac80211 cfg80211
      [<c0046090>] (unwind_backtrace+0x0/0x124) from [<c0064c10>] (warn_slowpath_common+0x4c/0x64)
      [<c0064c10>] (warn_slowpath_common+0x4c/0x64) from [<c0064c40>] (warn_slowpath_null+0x18/0x1c)
      [<c0064c40>] (warn_slowpath_null+0x18/0x1c) from [<bf040e34>] (ieee80211_duration+0x54/0x1d8 [mac80211])
      [<bf040e34>] (ieee80211_duration+0x54/0x1d8 [mac80211]) from [<bf04200c>] (invoke_tx_handlers+0xfa0/0x1088 [mac80211])
      [<bf04200c>] (invoke_tx_handlers+0xfa0/0x1088 [mac80211]) from [<bf042178>] (ieee80211_tx+0x84/0x248 [mac80211])
      [<bf042178>] (ieee80211_tx+0x84/0x248 [mac80211]) from [<bf042f44>] (ieee80211_tx_pending+0x12c/0x278 [mac80211])
      [<bf042f44>] (ieee80211_tx_pending+0x12c/0x278 [mac80211]) from [<c0069a9c>] (tasklet_action+0x68/0xbc)
      [<c0069a9c>] (tasklet_action+0x68/0xbc) from [<c006a044>] (__do_softirq+0x84/0x114)
      [<c006a044>] (__do_softirq+0x84/0x114) from [<c006a1b8>] (do_softirq+0x48/0x54)
      [<c006a1b8>] (do_softirq+0x48/0x54) from [<c006a4f8>] (local_bh_enable+0x98/0xcc)
      [<c006a4f8>] (local_bh_enable+0x98/0xcc) from [<bf074e60>] (wl1271_rx+0x2e8/0x3a4 [wl1271])
      [<bf074e60>] (wl1271_rx+0x2e8/0x3a4 [wl1271]) from [<bf071ae4>] (wl1271_irq_work+0x230/0x310 [wl1271])
      [<bf071ae4>] (wl1271_irq_work+0x230/0x310 [wl1271]) from [<c0076864>] (process_one_work+0x208/0x350)
      [<c0076864>] (process_one_work+0x208/0x350) from [<c0076e14>] (worker_thread+0x1cc/0x300)
      [<c0076e14>] (worker_thread+0x1cc/0x300) from [<c007bb88>] (kthread+0x84/0x8c)
      [<c007bb88>] (kthread+0x84/0x8c) from [<c0041494>] (kernel_thread_exit+0x0/0x8)
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8fd369ee
  10. 26 1月, 2011 1 次提交
  11. 20 1月, 2011 3 次提交
  12. 19 1月, 2011 1 次提交
  13. 05 1月, 2011 1 次提交
  14. 23 12月, 2010 1 次提交
  15. 21 12月, 2010 5 次提交
  16. 14 12月, 2010 1 次提交
  17. 09 12月, 2010 1 次提交
    • H
      mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs · 7e244707
      Helmut Schaa 提交于
      mac80211 doesn't handle shared skbs correctly at the moment. As a result
      a possible resize can trigger a BUG in pskb_expand_head.
      
      [  676.030000] Kernel bug detected[#1]:
      [  676.030000] Cpu 0
      [  676.030000] $ 0   : 00000000 00000000 819662ff 00000002
      [  676.030000] $ 4   : 81966200 00000020 00000000 00000020
      [  676.030000] $ 8   : 819662e0 800043c0 00000002 00020000
      [  676.030000] $12   : 3b9aca00 00000000 00000000 00470000
      [  676.030000] $16   : 80ea2000 00000000 00000000 00000000
      [  676.030000] $20   : 818aa200 80ea2018 80ea2000 00000008
      [  676.030000] $24   : 00000002 800ace5c
      [  676.030000] $28   : 8199a000 8199bd20 81938f88 80f180d4
      [  676.030000] Hi    : 0000026e
      [  676.030000] Lo    : 0000757e
      [  676.030000] epc   : 801245e4 pskb_expand_head+0x44/0x1d8
      [  676.030000]     Not tainted
      [  676.030000] ra    : 80f180d4 ieee80211_skb_resize+0xb0/0x114 [mac80211]
      [  676.030000] Status: 1000a403    KERNEL EXL IE
      [  676.030000] Cause : 10800024
      [  676.030000] PrId  : 0001964c (MIPS 24Kc)
      [  676.030000] Modules linked in: mac80211_hwsim rt2800lib rt2x00soc rt2x00pci rt2x00lib mac80211 crc_itu_t crc_ccitt cfg80211 compat arc4 aes_generic deflate ecb cbc [last unloaded: rt2800pci]
      [  676.030000] Process kpktgend_0 (pid: 97, threadinfo=8199a000, task=81879f48, tls=00000000)
      [  676.030000] Stack : ffffffff 00000000 00000000 00000014 00000004 80ea2000 00000000 00000000
      [  676.030000]         818aa200 80f180d4 ffffffff 0000000a 81879f78 81879f48 81879f48 00000018
      [  676.030000]         81966246 80ea2000 818432e0 80f1a420 80203050 81814d98 00000001 81879f48
      [  676.030000]         81879f48 00000018 81966246 818432e0 0000001a 8199bdd4 0000001c 80f1b72c
      [  676.030000]         80203020 8001292c 80ef4aa2 7f10b55d 801ab5b8 81879f48 00000188 80005c90
      [  676.030000]         ...
      [  676.030000] Call Trace:
      [  676.030000] [<801245e4>] pskb_expand_head+0x44/0x1d8
      [  676.030000] [<80f180d4>] ieee80211_skb_resize+0xb0/0x114 [mac80211]
      [  676.030000] [<80f1a420>] ieee80211_xmit+0x150/0x22c [mac80211]
      [  676.030000] [<80f1b72c>] ieee80211_subif_start_xmit+0x6f4/0x73c [mac80211]
      [  676.030000] [<8014361c>] pktgen_thread_worker+0xfac/0x16f8
      [  676.030000] [<8002ebe8>] kthread+0x7c/0x88
      [  676.030000] [<80008e0c>] kernel_thread_helper+0x10/0x18
      [  676.030000]
      [  676.030000]
      [  676.030000] Code: 24020001  10620005  2502001f <0200000d> 0804917a  00000000  2502001f  00441023  00531021
      
      Fix this by making a local copy of shared skbs prior to mangeling them.
      To avoid copying the skb unnecessarily move the skb_copy call below the
      checks that don't need write access to the skb.
      
      Also, move the assignment of nh_pos and h_pos below the skb_copy to point
      to the correct skb.
      
      It would be possible to avoid another resize of the copied skb by using
      skb_copy_expand instead of skb_copy but that would make the patch more
      complex. Also, shared skbs are a corner case right now, so the resize
      shouldn't matter much.
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7e244707
  18. 07 12月, 2010 1 次提交
  19. 30 11月, 2010 1 次提交
    • J
      mac80211: Fix frame injection using non-AP vif · 7dff3125
      Jouni Malinen 提交于
      In order for frame injection to work properly for some use cases
      (e.g., finding the station entry and keys for encryption), mac80211
      needs to find the correct sdata entry. This works when the main vif
      is in AP mode, but commit a2c1e3da
      broke this particular use case for station main vif. While this type of
      injection is quite unusual operation, it has some uses and we should fix
      it. Do this by changing the monitor vif sdata selection to allow station
      vif to be selected instead of limiting it to just AP vifs. We still need
      to skip some iftypes to avoid selecting unsuitable vif for injection.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7dff3125
  20. 17 11月, 2010 2 次提交
  21. 07 10月, 2010 1 次提交
  22. 06 10月, 2010 1 次提交
  23. 15 9月, 2010 1 次提交
  24. 28 8月, 2010 3 次提交
  25. 26 8月, 2010 2 次提交
  26. 17 8月, 2010 1 次提交
  27. 29 7月, 2010 1 次提交
  28. 27 7月, 2010 1 次提交
    • J
      mac80211: fix sta assignment · ec25acc4
      Johannes Berg 提交于
      I just had the following:
      WARNING: at drivers/net/wireless/iwlwifi/iwl-agn-tx.c:574 iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]()
      Call Trace:
       <IRQ>  [<ffffffff8105c5df>] warn_slowpath_common+0x7f/0xc0
       [<ffffffff8105c63a>] warn_slowpath_null+0x1a/0x20
       [<ffffffffa0290b46>] iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]
       [<ffffffffa027076c>] iwl_mac_tx+0x5c/0x260 [iwlagn]
       [<ffffffffa01bdf5b>] __ieee80211_tx+0x10b/0x1a0 [mac80211]
       [<ffffffffa01bfb86>] ieee80211_tx_pending+0x186/0x2d0 [mac80211]
       [<ffffffff81062ea5>] tasklet_action+0x125/0x130
       [<ffffffff810634a6>] __do_softirq+0x106/0x270
       [<ffffffff8100c09c>] call_softirq+0x1c/0x30
      iwlagn 0000:02:00.0: Attempting to modify non-existing station 107
      
      Note that 107 == 0x6b which is slab poison.
      
      The reason is that mac80211 passed a freed station
      pointer to mac80211, because as it happened iwlwifi
      reset itself while mac80211 was disconnecting from
      the network.
      
      It turns out that we do take care to look up the
      station pointer in ieee80211_tx_pending_skb, but
      then don't use it, which obviously is a bug. Fix
      this by removing the ieee80211_tx_h_sta handler
      and assigning the station pointer directly.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ec25acc4