1. 10 2月, 2012 1 次提交
    • M
      mac80211: Fix a rwlock bad magic bug · b57e6b56
      Mohammed Shafi Shajakhan 提交于
      read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path
      ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig
      (->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing
      it.
      the intilization of this read/write lock happens via the path
      ieee80211_led_init (->) led_trigger_register, but we are doing
      'ieee80211_led_init'  after 'ieeee80211_if_add' where we
      register netdev_ops.
      so we access leddev_list_lock before initializing it and causes the
      following bug in chrome laptops with AR928X cards with the following
      script
      
      while true
      do
      sudo modprobe -v ath9k
      sleep 3
      sudo modprobe -r ath9k
      sleep 3
      done
      
      	BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
      	Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
      	Call Trace:
      
      	[<8137b9df>] rwlock_bug+0x3d/0x47
      	[<81179830>] do_raw_read_lock+0x19/0x29
      	[<8137f063>] _raw_read_lock+0xd/0xf
      	[<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211]
      	[<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
      	[<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211]
      	[<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
      	[<f9076d97>] ieee80211_open+0x48/0x4c [mac80211]
      	[<812dbed8>] __dev_open+0x82/0xab
      	[<812dc0c9>] __dev_change_flags+0x9c/0x113
      	[<812dc1ae>] dev_change_flags+0x18/0x44
      	[<8132144f>] devinet_ioctl+0x243/0x51a
      	[<81321ba9>] inet_ioctl+0x93/0xac
      	[<812cc951>] sock_ioctl+0x1c6/0x1ea
      	[<812cc78b>] ? might_fault+0x20/0x20
      	[<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2
      	[<810a6ebb>] ? fget_light+0x2f/0x70
      	[<812ce549>] ? sys_recvmsg+0x3e/0x48
      	[<810b1f35>] sys_ioctl+0x46/0x69
      	[<8137fa77>] sysenter_do_call+0x12/0x2
      
      Cc: <stable@vger.kernel.org>
      Cc: Gary Morain <gmorain@google.com>
      Cc: Paul Stewart <pstew@google.com>
      Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Acked-by: NJohannes Berg <johannes.berg@intel.com>
      Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b57e6b56
  2. 14 12月, 2011 2 次提交
  3. 07 12月, 2011 1 次提交
  4. 01 12月, 2011 2 次提交
  5. 22 11月, 2011 3 次提交
  6. 10 11月, 2011 4 次提交
  7. 15 10月, 2011 1 次提交
    • H
      mac80211: Build TX radiotap header dynamically · a2fe8166
      Helmut Schaa 提交于
      Get rid of the ieee80211_tx_status_rtap_hdr struct and instead build the
      rtap header dynamically. This makes it easier to extend the rtap header
      generation in the future.
      
      Add ieee80211_tx_radiotap_len to calculate the expected size of the
      rtap header before generating it. Since we can't check if the rtap
      header fits into the requested headroom during compile time anymore
      add a WARN_ON_ONCE.
      
      Also move the actual rtap header generation into its own function.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a2fe8166
  8. 01 10月, 2011 2 次提交
    • J
      mac80211: allow out-of-band EOSP notification · 37fbd908
      Johannes Berg 提交于
      iwlwifi has a separate EOSP notification from
      the device, and to make use of that properly
      it needs to be passed to mac80211. To be able
      to mix with tx_status_irqsafe and rx_irqsafe
      it also needs to be an "_irqsafe" version in
      the sense that it goes through the tasklet,
      the actual flag clearing would be IRQ-safe
      but doing it directly would cause reordering
      issues.
      
      This is needed in the case of a P2P GO going
      into an absence period without transmitting
      any frames that should be driver-released as
      in this case there's no other way to inform
      mac80211 that the service period ended. Note
      that for drivers that don't use the _irqsafe
      functions another version of this function
      will be required.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37fbd908
    • A
      mac80211: handle TDLS high-level commands and frames · dfe018bf
      Arik Nemtsov 提交于
      Register and implement the TDLS cfg80211 callback functions.
      
      Internally prepare and send TDLS management frames. We incorporate
      local STA capabilities and supported rates with extra IEs given by
      usermode. The resulting packet is either encapsulated in a data frame,
      or assembled as an action frame. It is transmitted either directly or
      through the AP, as mandated by the TDLS specification.
      
      Declare support for the TDLS external setup wiphy capability. This
      tells usermode to handle link setup and discovery on its own, and use the
      kernel driver for sending TDLS mgmt packets.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Cc: Kalyan C Gaddam <chakkal@iit.edu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dfe018bf
  9. 25 8月, 2011 1 次提交
  10. 23 8月, 2011 1 次提交
    • S
      mac80211: fix suspend/resume races with unregister hw · ecb44335
      Stanislaw Gruszka 提交于
      Do not call ->suspend, ->resume methods after we unregister wiphy. Also
      delete sta_clanup timer after we finish wiphy unregister to avoid this:
      
      WARNING: at lib/debugobjects.c:262 debug_print_object+0x85/0xa0()
      Hardware name: 6369CTO
      ODEBUG: free active (active state 0) object type: timer_list hint: sta_info_cleanup+0x0/0x180 [mac80211]
      Modules linked in: aes_i586 aes_generic fuse bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq mperf ext2 dm_mod uinput thinkpad_acpi hwmon sg arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 i2c_i801 iTCO_wdt iTCO_vendor_support e1000e ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom yenta_socket ahci libahci pata_acpi ata_generic ata_piix i915 drm_kms_helper drm i2c_algo_bit video [last unloaded: microcode]
      Pid: 5663, comm: pm-hibernate Not tainted 3.1.0-rc1-wl+ #19
      Call Trace:
       [<c0454cfd>] warn_slowpath_common+0x6d/0xa0
       [<c05e05e5>] ? debug_print_object+0x85/0xa0
       [<c05e05e5>] ? debug_print_object+0x85/0xa0
       [<c0454dae>] warn_slowpath_fmt+0x2e/0x30
       [<c05e05e5>] debug_print_object+0x85/0xa0
       [<f8a808e0>] ? sta_info_alloc+0x1a0/0x1a0 [mac80211]
       [<c05e0bd2>] debug_check_no_obj_freed+0xe2/0x180
       [<c051175b>] kfree+0x8b/0x150
       [<f8a126ae>] cfg80211_dev_free+0x7e/0x90 [cfg80211]
       [<f8a13afd>] wiphy_dev_release+0xd/0x10 [cfg80211]
       [<c068d959>] device_release+0x19/0x80
       [<c05d06ba>] kobject_release+0x7a/0x1c0
       [<c07646a8>] ? rtnl_unlock+0x8/0x10
       [<f8a13adb>] ? wiphy_resume+0x6b/0x80 [cfg80211]
       [<c05d0640>] ? kobject_del+0x30/0x30
       [<c05d1a6d>] kref_put+0x2d/0x60
       [<c05d056d>] kobject_put+0x1d/0x50
       [<c08015f4>] ? mutex_lock+0x14/0x40
       [<c068d60f>] put_device+0xf/0x20
       [<c069716a>] dpm_resume+0xca/0x160
       [<c04912bd>] hibernation_snapshot+0xcd/0x260
       [<c04903df>] ? freeze_processes+0x3f/0x90
       [<c049151b>] hibernate+0xcb/0x1e0
       [<c048fdc0>] ? pm_async_store+0x40/0x40
       [<c048fe60>] state_store+0xa0/0xb0
       [<c048fdc0>] ? pm_async_store+0x40/0x40
       [<c05d0200>] kobj_attr_store+0x20/0x30
       [<c0575ea4>] sysfs_write_file+0x94/0xf0
       [<c051e26a>] vfs_write+0x9a/0x160
       [<c0575e10>] ? sysfs_open_file+0x200/0x200
       [<c051e3fd>] sys_write+0x3d/0x70
       [<c080959f>] sysenter_do_call+0x12/0x28
      
      Cc: stable@kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ecb44335
  11. 09 8月, 2011 1 次提交
  12. 17 5月, 2011 4 次提交
    • J
      mac80211: add missing rcu_barrier · d07c7cf4
      Johannes Berg 提交于
      mac80211 uses call_rcu() with functions that are
      defined in the module, so it must use rcu_barrier()
      at module exit time.
      
      Luckily, this seems to not be a problem in practice
      as module unload and unregistration takes a long
      time and probably does multiple synchronize_rcu().
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d07c7cf4
    • J
      mac80211: verify IBSS in interface combinations · 8e621fc9
      Johannes Berg 提交于
      Drivers shouldn't attempt to advertise support
      for more than one IBSS interface since mac80211
      doesn't support that. Check and return an error
      from ieee80211_register_hw() in that case.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e621fc9
    • 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
      cfg80211: advertise possible interface combinations · 7527a782
      Johannes Berg 提交于
      Add the ability to advertise interface combinations in nl80211.
      This allows the driver to indicate what the combinations are
      that it supports. "Combinations" of just a single interface are
      implicit, as previously. Note that cfg80211 will enforce that
      the restrictions are met, but not for all drivers yet (once all
      drivers are updated, we can remove the flag and enforce for all).
      
      When no combinations are actually supported, an empty list will
      be exported so that userspace can know if the kernel exported
      this info or not (although it isn't clear to me what tools using
      the info should do if the kernel didn't export it).
      
      Since some interface types are purely virtual/software and don't
      fit the restrictions, those are exposed in a new list of pure SW
      types, not subject to restrictions. This mainly exists to handle
      AP-VLAN and monitor interfaces in mac80211.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7527a782
  13. 13 5月, 2011 1 次提交
  14. 12 5月, 2011 1 次提交
  15. 11 5月, 2011 1 次提交
    • L
      mac80211: Fix build error when CONFIG_PM is not defined · 38bb3e9d
      Larry Finger 提交于
      When mac80211 is built without CONFIG_PM being defined, the following errors
      are output:
      
      net/mac80211/main.c: In function ‘ieee80211_register_hw’:
      net/mac80211/main.c:700: error: ‘const struct ieee80211_ops’ has no member named ‘suspend’
      net/mac80211/main.c:700: error: ‘const struct ieee80211_ops’ has no member named ‘resume’
      make[2]: *** [net/mac80211/main.o] Error 1
      make[1]: *** [net/mac80211] Error 2
      make[1]: *** Waiting for unfinished jobs....
      make: *** [net] Error 2
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      38bb3e9d
  16. 06 5月, 2011 2 次提交
  17. 26 4月, 2011 1 次提交
  18. 13 4月, 2011 2 次提交
  19. 05 4月, 2011 1 次提交
  20. 08 3月, 2011 1 次提交
  21. 19 2月, 2011 1 次提交
  22. 10 2月, 2011 2 次提交
  23. 05 2月, 2011 1 次提交
    • B
      mac80211: Optimize scans on current operating channel. · b23b025f
      Ben Greear 提交于
      This should decrease un-necessary flushes, on/off channel work,
      and channel changes in cases where the only scanned channel is
      the current operating channel.
      
      * Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
        and is-scanning flags instead.
      
      * Add helper method to determine if we are currently configured
        for the operating channel.
      
      * Do no blindly go off/on channel in work.c  Instead, only call
        appropriate on/off code when we really need to change channels.
        Always enable offchannel-ps mode when starting work,
        and disable it when we are done.
      
      * Consolidate ieee80211_offchannel_stop_station and
        ieee80211_offchannel_stop_beaconing, call it
        ieee80211_offchannel_stop_vifs instead.
      
      * Accept non-beacon frames when scanning on operating channel.
      
      * Scan state machine optimized to minimize on/off channel
        transitions.  Also, when going on-channel, go ahead and
        re-enable beaconing.  We're going to be there for 200ms,
        so seems like some useful beaconing could happen.
        Always enable offchannel-ps mode when starting software
        scan, and disable it when we are done.
      
      * Grab local->mtx earlier in __ieee80211_scan_completed_finish
        so that we are protected when calling hw_config(), etc.
      
      * Pass probe-responses up the stack if scanning on local
        channel, so that mlme can take a look.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b23b025f
  24. 20 1月, 2011 1 次提交
  25. 14 1月, 2011 1 次提交
  26. 06 1月, 2011 1 次提交