1. 06 May, 2015 8 commits
  2. 05 May, 2015 7 commits
  3. 24 Apr, 2015 12 commits
  4. 23 Apr, 2015 1 commit
  5. 22 Apr, 2015 10 commits
  6. 20 Apr, 2015 2 commits
    • Jonathan Corbet's avatar
      mac80211: Fix mac80211.h docbook comments · a839e463
      Jonathan Corbet authored
      A couple of enums in mac80211.h became structures recently, but the
      comments didn't follow suit, leading to errors like:
      
        Error(.//include/net/mac80211.h:367): Cannot parse enum!
        Documentation/DocBook/Makefile:93: recipe for target 'Documentation/DocBook/80211.xml' failed
        make[1]: *** [Documentation/DocBook/80211.xml] Error 1
        Makefile:1361: recipe for target 'mandocs' failed
        make: *** [mandocs] Error 2
      
      Fix the comments comments accordingly.  Added a couple of other small
      comment fixes while I was there to silence other recently-added docbook
      warnings.
      Reported-by: default avatarJim Davis <jim.epost@gmail.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a839e463
    • Johannes Berg's avatar
      mac80211: lock rate control · 35c347ac
      Johannes Berg authored
      Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
      control aren't properly taking concurrency into account. It's
      likely that the same is true for other rate control algorithms.
      
      In the case of minstrel this manifests itself in crashes when an
      update and other data access are run concurrently, for example
      when the stations change bandwidth or similar. In iwlwifi, this
      can cause firmware crashes.
      
      Since fixing all rate control algorithms will be very difficult,
      just provide locking for invocations. This protects the internal
      data structures the algorithms maintain.
      
      I've manipulated hostapd to test this, by having it change its
      advertised bandwidth roughly ever 150ms. At the same time, I'm
      running a flood ping between the client and the AP, which causes
      this race of update vs. get_rate/status to easily happen on the
      client. With this change, the system survives this test.
      Reported-by: default avatarSven Eckelmann <sven@open-mesh.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      35c347ac