1. 25 5月, 2010 1 次提交
  2. 20 4月, 2010 1 次提交
    • D
      ath9k: Group Key fix for VAPs · 03ceedea
      Daniel Yingqiang Ma 提交于
      When I set up multiple VAPs with ath9k, I encountered an issue that
      the traffic may be lost after a while.
      
      The detailed phenomenon is
      1. After a while the clients connected to one of these VAPs will get
      into a state that no broadcast/multicast packets can be transfered
      successfully while the unicast packets can be transfered normally.
      2. Minutes latter the unitcast packets transfer will fail as well,
      because the ARP entry is expired and it can't be freshed due to the
      broadcast trouble.
      
      It's caused by the group key overwritten and someone discussed this
      issue in ath9k-devel maillist before, but haven't work out a fix yet.
      
      I referred the method in madwifi, and made a patch for ath9k.
      The method is to set the high bit of the sender(AP)'s address, and
      associated that mac and the group key. It requires the hardware
      supports multicast frame key search. It seems true for AR9160.
      
      Not sure whether it's the correct way to fix this issue. But it seems
      to work in my test. The patch is attached, feel free to revise it.
      Signed-off-by: NDaniel Yingqiang ma <yma.cool@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      03ceedea
  3. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  4. 29 12月, 2009 1 次提交
  5. 22 12月, 2009 2 次提交
  6. 18 8月, 2009 1 次提交
  7. 11 7月, 2009 1 次提交
  8. 21 5月, 2009 1 次提交
  9. 14 5月, 2009 1 次提交
    • J
      nl80211: Add RSC configuration for new keys · faa8fdc8
      Jouni Malinen 提交于
      When setting a key with NL80211_CMD_NEW_KEY, we should allow the key
      sequence number (RSC) to be set in order to allow replay protection to
      work correctly for group keys. This patch documents this use for
      nl80211 and adds the couple of missing pieces in nl80211/cfg80211 and
      mac80211 to support this. In addition, WEXT SIOCSIWENCODEEXT compat
      processing in cfg80211 is extended to handle the RSC (this was already
      specified in WEXT, but just not implemented in cfg80211/mac80211).
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      faa8fdc8
  10. 07 5月, 2009 1 次提交
  11. 28 2月, 2009 1 次提交
    • J
      mac80211: split IBSS/managed code · 46900298
      Johannes Berg 提交于
      This patch splits out the ibss code and data from managed (station) mode.
      The reason to do this is to better separate the state machines, and have
      the code be contained better so it gets easier to determine what exactly
      a given change will affect, that in turn makes it easier to understand.
      
      This is quite some churn, especially because I split sdata->u.sta into
      sdata->u.mgd and sdata->u.ibss, but I think it's easier to maintain that
      way. I've also shuffled around some code -- null function sending is only
      applicable to managed interfaces so put that into that file, some other
      functions are needed from various places so put them into util, and also
      rearranged the prototypes in ieee80211_i.h accordingly.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      46900298
  12. 30 1月, 2009 2 次提交
  13. 28 10月, 2008 1 次提交
  14. 07 10月, 2008 1 次提交
  15. 16 9月, 2008 2 次提交
  16. 28 6月, 2008 1 次提交
  17. 15 5月, 2008 1 次提交
    • J
      mac80211: proper STA info locking · 07346f81
      Johannes Berg 提交于
      As discussed earlier, we can unify locking in struct sta_info
      and use just a single spinlock protecting all members of the
      structure that need protection. Many don't, but one of the
      especially bad ones is the 'flags' member that can currently
      be clobbered when RX and TX is being processed on different
      CPUs at the same time.
      
      Because having four spinlocks for different, mostly exclusive
      parts of a single structure is overkill, this patch also kills
      the ampdu and mesh plink spinlocks and uses just a single one
      for everything. Because none of the spinlocks are nested, this
      is safe.
      
      It remains to be seen whether or not we should make the sta
      flags use atomic bit operations instead, for now though this
      is a safe thing and using atomic operations instead will be
      very simple using the new static inline functions this patch
      introduces for accessing sta->flags.
      
      Since spin_lock_bh() is used with this lock, there shouldn't
      be any contention even if aggregation is enabled at around the
      same time as both requires frame transmission/reception which
      is in a bh context.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Tomas Winkler <tomasw@gmail.com>
      Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
      Cc: Luis Carlos Cobo <luisca@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      07346f81
  18. 08 5月, 2008 1 次提交
  19. 17 4月, 2008 3 次提交
  20. 09 4月, 2008 1 次提交
    • J
      mac80211: fix key vs. sta locking problems · 3b96766f
      Johannes Berg 提交于
      Up to now, key manipulation is supposed to run under RTNL to
      avoid concurrent manipulations and also allow the set_key()
      hardware callback to sleep. This is not feasible because STA
      structs are rcu-protected and thus a lot of operations there
      cannot take the RTNL. Also, key references are rcu-protected
      so we cannot do things atomically.
      
      This patch changes key locking completely:
       * key operations are now atomic
       * hardware crypto offload is enabled and disabled from
         a workqueue, due to that key freeing is also delayed
       * debugfs code is also run from a workqueue
       * keys reference STAs (and vice versa!) so during STA
         unlink the STAs key reference is removed but not the
         keys STA reference, to avoid races key todo work is
         run before STA destruction.
       * fewer STA operations now need the RTNL which was
         required due to key operations
      
      This fixes the locking problems lockdep pointed out and also
      makes things more light-weight because the rtnl isn't required
      as much.
      
      Note that the key todo lock/key mutex are global locks, this
      is not required, of course, they could be per-hardware instead.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3b96766f
  21. 02 4月, 2008 1 次提交
  22. 07 3月, 2008 3 次提交
  23. 01 3月, 2008 2 次提交
    • J
      mac80211: fix key replacing, hw accel · e4861829
      Johannes Berg 提交于
      Even though I thought about it a lot and had also tested it, some
      of my recent changes in the key code broke replacing keys, making
      the kernel oops because a key is removed from a list while not on
      it.
      
      This patch fixes that using the list as an indication whether or
      not the key is on it (an empty list means it's not on any list.)
      
      Also, this patch fixes hw accel enabling, the check for not doing
      hw accel when the interface is down was lost and is restored by
      this.
      
      Additionally, move adding the key to the list into the function
      __ieee80211_key_replace() for more consistency.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e4861829
    • J
      mac80211: split ieee80211_key_alloc/free · db4d1169
      Johannes Berg 提交于
      In order to RCU-ify sta_info, we need to be able to allocate
      a key without linking it to an sdata/sta structure (because
      allocation cannot be done in an rcu critical section). This
      patch splits up ieee80211_key_alloc() and updates all users
      appropriately.
      
      While at it, this patch fixes a number of race conditions
      such as finally making key replacement atomic, unfortunately
      at the expense of more complex code.
      
      Note that this patch documents /existing/ bugs with sta info
      and key interaction, there is currently a race condition
      when a sta info is freed without holding the RTNL. This will
      finally be fixed by a followup patch.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      db4d1169
  24. 29 1月, 2008 1 次提交
  25. 11 10月, 2007 8 次提交
    • J
      [MAC80211]: remove ALG_NONE · 628a140b
      Johannes Berg 提交于
      This "algorithm" is used only internally and is not useful.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Michael Buesch <mb@bu3sch.de>
      Acked-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      628a140b
    • J
      [PATCH] mac80211: remove crypto algorithm typedef · ea49c359
      Johannes Berg 提交于
      The typedef is not required, we can just use "enum ieee80211_key_alg"
      instead of "ieee80211_key_alg"
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NMichael Wu <flamingice@sourmilk.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ea49c359
    • J
      [NET]: Introduce and use print_mac() and DECLARE_MAC_BUF() · 0795af57
      Joe Perches 提交于
      This is nicer than the MAC_FMT stuff.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0795af57
    • J
      [MAC80211]: remove HW_KEY_IDX_INVALID · 6a7664d4
      Johannes Berg 提交于
      This patch makes the mac80211/driver interface rely only on the
      IEEE80211_TXCTL_DO_NOT_ENCRYPT flag to signal to the driver whether
      a frame should be encrypted or not, since mac80211 internally no
      longer relies on HW_KEY_IDX_INVALID either this removes it, changes
      the key index to be a u8 in all places and makes the full range of
      the value available to drivers.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMichael Wu <flamingice@sourmilk.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a7664d4
    • J
      [MAC80211]: remove set_key_idx callback · c15a2050
      Johannes Berg 提交于
      No existing drivers use this callback, hence there's no telling
      how it might be used. In fact, it is unlikely to be of much use
      as-is because the default key index isn't something that the
      driver can do much with without knowing which interface it was
      for etc. And if it needs the key index for the transmitted frame,
      it can get it by keeping a reference to the key_conf structure
      and looking it up by hw_key_idx.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMichael Wu <flamingice@sourmilk.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c15a2050
    • J
      [MAC80211]: fix race conditions with keys · d4e46a3d
      Johannes Berg 提交于
      During receive processing, we select the key long before using it and
      because there's no locking it is possible that we kfree() the key
      after having selected it but before using it for crypto operations.
      Obviously, this is bad.
      
      Secondly, during transmit processing, there are two possible races: We
      have a similar race between select_key() and using it for encryption,
      but we also have a race here between select_key() and hardware
      encryption (both when a key is removed.)
      
      This patch solves these issues by using RCU: when a key is to be freed,
      we first remove the pointer from the appropriate places (sdata->keys,
      sdata->default_key, sta->key) using rcu_assign_pointer() and then
      synchronize_rcu(). Then, we can safely kfree() the key and remove it
      from the hardware. There's a window here where the hardware may still
      be using it for decryption, but we can't work around that without having
      two hardware callbacks, one to disable the key for RX and one to disable
      it for TX; but the worst thing that will happen is that we receive a
      packet decrypted that we don't find a key for any more and then drop it.
      
      When we add a key, we first need to upload it to the hardware and then,
      using rcu_assign_pointer() again, link it into our structures.
      
      In the code using keys (TX/RX paths) we use rcu_dereference() to get the
      key and enclose the whole tx/rx section in a rcu_read_lock() ...
      rcu_read_unlock() block. Because we've uploaded the key to hardware
      before linking it into internal structures, we can guarantee that it is
      valid once get to into tx().
      
      One possible race condition remains, however: when we have hardware
      acceleration enabled and the driver shuts down the queues, we end up
      queueing the frame. If now somebody removes the key, the key will be
      removed from hwaccel and then then driver will be asked to encrypt the
      frame with a key index that has been removed. Hence, drivers will need
      to be aware that the hw_key_index they are passed might not be under
      all circumstances. Most drivers will, however, simply ignore that
      condition and encrypt the frame with the selected key anyway, this
      only results in a frame being encrypted with a wrong key or dropped
      (rightfully) because the key was not valid. There isn't much we can
      do about it unless we want to walk the pending frame queue every time
      a key is removed and remove all frames that used it.
      
      This race condition, however, will most likely be solved once we add
      multiqueue support to mac80211 because then frames will be queued
      further up the stack instead of after being processed.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMichael Wu <flamingice@sourmilk.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4e46a3d
    • J
      [MAC80211]: rework key handling · 11a843b7
      Johannes Berg 提交于
      This moves all the key handling code out from ieee80211_ioctl.c
      into key.c and also does the following changes including documentation
      updates in mac80211.h:
      
       1) Turn off hardware acceleration for keys when the interface
          is down. This is necessary because otherwise monitor
          interfaces could be decrypting frames for other interfaces
          that are down at the moment. Also, it should go some way
          towards better suspend/resume support, in any case the
          routines used here could be used for that as well.
          Additionally, this makes the driver interface nicer, keys
          for a specific local MAC address are only ever present
          while an interface with that MAC address is enabled.
      
       2) Change driver set_key() callback interface to allow only
          return values of -ENOSPC, -EOPNOTSUPP and 0, warn on all
          other return values. This allows debugging the stack when
          a driver notices it's handed a key while it is down.
      
       3) Invert the flag meaning to KEY_FLAG_UPLOADED_TO_HARDWARE.
      
       4) Remove REMOVE_ALL_KEYS command as it isn't used nor do we
          want to use it, we'll use DISABLE_KEY for each key. It is
          hard to use REMOVE_ALL_KEYS because we can handle multiple
          virtual interfaces with different key configuration, so we'd
          have to keep track of a lot of state for this and that isn't
          worth it.
      
       5) Warn when disabling a key fails, it musn't.
      
       6) Remove IEEE80211_HW_NO_TKIP_WMM_HWACCEL in favour of per-key
          IEEE80211_KEY_FLAG_WMM_STA to let driver sort it out itself.
      
       7) Tell driver that a (non-WEP) key is used only for transmission
          by using an all-zeroes station MAC address when configuring.
      
       8) Change the set_key() callback to have access to the local MAC
          address the key is being added for.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMichael Wu <flamingice@sourmilk.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11a843b7
    • J
      [MAC80211]: remove krefs for keys · 8f37171a
      Johannes Berg 提交于
      they aren't really refcounted anyway
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMichael Wu <flamingice@sourmilk.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f37171a