1. 25 7月, 2009 14 次提交
  2. 22 7月, 2009 3 次提交
    • J
      mac80211: use correct address for mesh Path Error · 35946a57
      Javier Cardona 提交于
      For forwarded frames, we save the precursor address in addr1 in case it
      needs to be used to send a Path Error.  mesh_path_discard_frame,
      however, was using addr2 instead of addr1 to send Path Error frames, so
      correct that and also make the comment regarding this more clear.
      Signed-off-by: NAndrey Yurovsky <andrey@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      35946a57
    • P
      mac80211: fix injection in monitor mode · 8ef86c7b
      Pavel Roskin 提交于
      The location of the 802.11 header is calculated incorrectly due to a
      wrong placement of parentheses.  Found by kmemcheck.
      Signed-off-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8ef86c7b
    • J
      mac80211: disable mesh · e2e414d9
      Johannes Berg 提交于
      My kvm instance was complaining a lot about sleeping
      in atomic contexts in the mesh code, and it turns out
      that both mesh_path_add() and mpp_path_add() need to
      be able to sleep (they even use synchronize_rcu()!).
      I put in a might_sleep() to annotate that, but I see
      no way, at least right now, of actually making sure
      those functions are only called from process context
      since they are both called during TX and RX and the
      mesh code itself even calls them with rcu_read_lock()
      "held".
      
      Therefore, let's disable it completely for now.
      
      It's possible that I'm only seeing this because the
      hwsim's beaconing is broken and thus the peers aren't
      discovered right away, but it is possible that this
      happens even if beaconing is working, for a peer that
      doesn't exist or so.
      
      It should be possible to solve this by deferring the
      freeing of the tables to call_rcu() instead of using
      synchronize_rcu(), and also using atomic allocations,
      but maybe it makes more sense to rework the code to
      not call these from atomic contexts and defer more of
      the work to the workqueue. Right now, I can't work on
      either of those solutions though.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e2e414d9
  3. 11 7月, 2009 23 次提交