1. 13 Sep, 2011 1 commit
  2. 27 Jul, 2011 1 commit
    • Neil Horman's avatar
      net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared · 550fd08c
      Neil Horman authored
      After the last patch, We are left in a state in which only drivers calling
      ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
      hardware call ether_setup for their net_devices and don't hold any state in
      their skbs.  There are a handful of drivers that violate this assumption of
      course, and need to be fixed up.  This patch identifies those drivers, and marks
      them as not being able to support the safe transmission of skbs by clearning the
      IFF_TX_SKB_SHARING flag in priv_flags
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Karsten Keil <isdn@linux-pingi.de>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Patrick McHardy <kaber@trash.net>
      CC: Krzysztof Halasa <khc@pm.waw.pl>
      CC: "John W. Linville" <linville@tuxdriver.com>
      CC: Greg Kroah-Hartman <gregkh@suse.de>
      CC: Marcel Holtmann <marcel@holtmann.org>
      CC: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 13 Jul, 2011 1 commit
  4. 11 Jul, 2011 1 commit
  5. 03 Jun, 2011 1 commit
  6. 16 May, 2011 2 commits
  7. 05 May, 2011 1 commit
  8. 20 Feb, 2011 1 commit
    • Eric W. Biederman's avatar
      net: Fix more stale on-stack list_head objects. · 5f04d506
      Eric W. Biederman authored
      From: Eric W. Biederman <ebiederm@xmission.com>
      In the beginning with batching unreg_list was a list that was used only
      once in the lifetime of a network device (I think).  Now we have calls
      using the unreg_list that can happen multiple times in the life of a
      network device like dev_deactivate and dev_close that are also using the
      unreg_list.  In addition in unregister_netdevice_queue we also do a
      list_move because for devices like veth pairs it is possible that
      unregister_netdevice_queue will be called multiple times.
      So I think the change below to fix dev_deactivate which Eric D. missed
      will fix this problem.  Now to go test that.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  9. 03 Feb, 2011 1 commit
  10. 05 Jan, 2011 1 commit
  11. 22 Dec, 2010 2 commits
  12. 06 Dec, 2010 2 commits
  13. 08 Nov, 2010 1 commit
    • Brian Cavagnolo's avatar
      mac80211: unset SDATA_STATE_OFFCHANNEL when cancelling a scan · 352ffad6
      Brian Cavagnolo authored
      For client STA interfaces, ieee80211_do_stop unsets the relevant
      interface's SDATA_STATE_RUNNING state bit prior to cancelling an
      interrupted scan.  When ieee80211_offchannel_return is invoked as
      part of cancelling the scan, it doesn't bother unsetting the
      SDATA_STATE_OFFCHANNEL bit because it sees that the interface is
      down.  Normally this doesn't matter because when the client STA
      interface is brought back up, it will probably issue a scan.  But
      in some cases (e.g., the user changes the interface type while it
      is down), the SDATA_STATE_OFFCHANNEL bit will remain set.  This
      prevents the interface queues from being started.  So we
      cancel the scan before unsetting the SDATA_STATE_RUNNING bit.
      Signed-off-by: default avatarBrian Cavagnolo <brian@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  14. 13 Oct, 2010 1 commit
  15. 06 Oct, 2010 1 commit
  16. 05 Oct, 2010 2 commits
  17. 16 Sep, 2010 2 commits
  18. 27 Aug, 2010 5 commits
  19. 25 Aug, 2010 1 commit
  20. 24 Aug, 2010 1 commit
  21. 16 Aug, 2010 2 commits
  22. 20 Jul, 2010 2 commits
  23. 14 Jun, 2010 7 commits
    • Juuso Oikarinen's avatar
      mac80211: Fix circular locking dependency in ARP filter handling · 68542962
      Juuso Oikarinen authored
      There is a circular locking dependency when configuring the
      hardware ARP filters on association, occurring when flushing the mac80211
      workqueue. This is what happens:
      [   92.026800] =======================================================
      [   92.030507] [ INFO: possible circular locking dependency detected ]
      [   92.030507] 2.6.34-04781-g2b2c009e #85
      [   92.030507] -------------------------------------------------------
      [   92.030507] modprobe/5225 is trying to acquire lock:
      [   92.030507]  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq
      [   92.030507]
      [   92.030507] but task is already holding lock:
      [   92.030507]  (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]
      [   92.030507] which lock already depends on the new lock.
      [   92.030507]
      [   92.030507]
      [   92.030507] the existing dependency chain (in reverse order) is:
      [   92.030507]
      [   92.030507] -> #2 (rtnl_mutex){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff81341754>] mutex_lock_nested+0x44/0x300
      [   92.030507]        [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]        [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211]
      [   92.030507]        [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211]
      [   92.030507] -> #1 ((&local->work_work)){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105a51a>] worker_thread+0x22a/0x370
      [   92.030507]        [<ffffffff8105ecc6>] kthread+0x96/0xb0
      [   92.030507]        [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
      [   92.030507]
      [   92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}:
      [   92.030507]        [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0
      [   92.030507]        [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211]
      [   92.030507]        [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211]
      The locking in this case is quite complex. Fix the problem by rewriting the
      way the hardware ARP filter list is handled - i.e. make a copy of the address
      list to the bss_conf struct, and provide that list to the hardware driver
      when needed.
      The current patch will enable filtering also in promiscuous mode. This may need
      to be changed in the future.
      Reported-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: change RX aggregation locking · a93e3644
      Johannes Berg authored
      To prepare for allowing drivers to sleep in
      ampdu_action, change the locking in the RX
      aggregation code to use a mutex, so that it
      would already allow drivers to sleep. But
      explicitly disable BHs around the callback
      for now since the TX part cannot yet sleep,
      and drivers' locking might require it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: move aggregation callback processing · c1475ca9
      Johannes Berg authored
      This moves the aggregation callback processing
      to the per-sdata skb queue and a work function
      rather than the tasklet.
      Unfortunately, this means that it extends the
      pkt_type hack to that skb queue. However, it
      will enable making ampdu_action API changes
      gradually, my current plan is to get rid of
      this again by forcing drivers to only return
      from ampdu_action() when everything is done,
      thus removing the callbacks completely.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: move blockack stop due to fragmentation · 344eec67
      Johannes Berg authored
      There's a corner case where we receive a fragmented
      frame during a blockack session, in which case we
      will terminate that session. To simplify future work
      in this area that will culminate in allowing the
      driver callbacks for aggregation to sleep, move the
      processing of this case out of the RX path into the
      interface work.
      This will simplify future work because the new place
      for this code doesn't require that the function will
      always be atomic, which the RX path needs.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: always process blockack action from workqueue · bed7ee6e
      Johannes Berg authored
      To prepare for making the ampdu_action callback
      sleep, make mac80211 always process blockack
      action frames from the skb queue. This gets rid
      of the current special case for managed mode
      interfaces as well.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: common work skb freeing · 36b3a628
      Johannes Berg authored
      All the management processing functions free the
      skb after they are done, so this can be done in
      the new common code instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: use common work function · 1fa57d01
      Johannes Berg authored
      Even with the previous patch, IBSS, managed
      and mesh modes all attach their own work
      function to the shared work struct, which
      means some duplicated code. Change that to
      only have a frame processing function and a
      further work function for each of them and
      share some common code.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>