1. 14 12月, 2011 1 次提交
    • Y
      mac80211: Purge A-MPDU TX queues before station destructions · 42624d49
      Yogesh Ashok Powar 提交于
      When a station leaves suddenly while ampdu traffic to that station is still
      running, there is a possibility that the ampdu pending queues are not freed due
      to a race condition leading to memory leaks. In '__sta_info_destroy' when we
      attempt to destroy the ampdu sessions in 'ieee80211_sta_tear_down_BA_sessions',
      the driver calls 'ieee80211_stop_tx_ba_cb_irqsafe' to delete the ampdu
      structures (tid_tx) and splice the pending queues and this job gets queued in
      sdata workqueue. However, the sta entry can get destroyed before the above work
      gets scheduled and hence the race.
      
      Purging the queues and freeing the tid_tx to avoid the leak. The better solution
      would be to fix the race, but that can be taken up in a separate patch.
      Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
      Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42624d49
  2. 07 12月, 2011 2 次提交
  3. 29 11月, 2011 5 次提交
  4. 09 11月, 2011 1 次提交
  5. 01 11月, 2011 1 次提交
  6. 01 10月, 2011 1 次提交
    • J
      mac80211: optimise station flags · c2c98fde
      Johannes Berg 提交于
      The flaglock in struct sta_info has long been
      something that I wanted to get rid of, this
      finally does the conversion to atomic bitops.
      
      The conversion itself is straight-forward in
      most places, a few things needed to change a
      bit since we can no longer use multiple bits
      at the same time.
      
      On x86-64, this is a fairly significant code
      size reduction:
         text	   data	    bss	    dec	    hex
       427861	  23648	   1008	 452517	  6e7a5	before
       425383	  23648	    976	 450007	  6ddd7	after
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2c98fde
  7. 15 9月, 2011 1 次提交
  8. 14 9月, 2011 2 次提交
  9. 23 8月, 2011 1 次提交
  10. 09 8月, 2011 1 次提交
  11. 17 5月, 2011 2 次提交
    • J
      mac80211: sparse RCU annotations · 40b275b6
      Johannes Berg 提交于
      This adds sparse RCU annotations to most of
      mac80211, only the mesh code remains to be
      done.
      
      Due the the previous patches, the annotations
      are pretty simple. The only thing that this
      actually changes is removing the RCU usage of
      key->sta in debugfs since this pointer isn't
      actually an RCU-managed pointer (it only has
      a single assignment done before the key even
      goes live). As that is otherwise harmless, I
      decided to make it part of this patch.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      40b275b6
    • J
      mac80211: fix TX a-MPDU locking · ec034b20
      Johannes Berg 提交于
      During my quest to make mac80211 not have any RCU
      warnings from sparse, I came across the a-MPDU code
      again and it wasn't quite clear why it isn't racy.
      So instead of assigning the tid_tx array with just
      the spinlock held in ieee80211_start_tx_ba_session
      use a separate temporary array protected only by
      the spinlock and protect all assignments to the
      "live" array by both the spinlock and the mutex so
      that other code is easily verified to be correct.
      
      Due to pointer assignment atomicity I don't think
      this is a real issue, but I'm not sure, especially
      on Alpha the current code might be problematic.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ec034b20
  12. 08 5月, 2011 1 次提交
  13. 20 1月, 2011 2 次提交
    • J
      mac80211: allow advertising correct maximum aggregate size · 5dd36bc9
      Johannes Berg 提交于
      Currently, mac80211 always advertises that it may send
      up to 64 subframes in an aggregate. This is fine, since
      it's the max, but might as well be set to zero instead
      since it doesn't have any information.
      
      However, drivers might have that information, so allow
      them to set a variable giving it, which will then be
      used. The default of zero will be fine since to the
      peer that means we don't know and it will just use its
      own limit for the buffer size.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5dd36bc9
    • J
      mac80211: track receiver's aggregation reorder buffer size · 0b01f030
      Johannes Berg 提交于
      The aggregation code currently doesn't implement the
      buffer size negotiation. It will always request a max
      buffer size (which is fine, if a little pointless, as
      the mac80211 code doesn't know and might just use 0
      instead), but if the peer requests a smaller size it
      isn't possible to honour this request.
      
      In order to fix this, look at the buffer size in the
      addBA response frame, keep track of it and pass it to
      the driver in the ampdu_action callback when called
      with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
      way the driver can limit the number of subframes in
      aggregates appropriately.
      
      Note that this doesn't fix any drivers apart from the
      addition of the new argument -- they all need to be
      updated separately to use this variable!
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b01f030
  14. 16 12月, 2010 1 次提交
  15. 07 10月, 2010 2 次提交
  16. 15 6月, 2010 10 次提交
  17. 04 6月, 2010 1 次提交
  18. 02 6月, 2010 1 次提交
  19. 20 4月, 2010 2 次提交
  20. 09 4月, 2010 1 次提交
  21. 08 4月, 2010 1 次提交