1. 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
  2. 20 7月, 2011 1 次提交
  3. 16 7月, 2011 3 次提交
  4. 12 7月, 2011 1 次提交
  5. 07 7月, 2011 1 次提交
    • J
      cfg80211/nl80211: support GTK rekey offload · e5497d76
      Johannes Berg 提交于
      In certain circumstances, like WoWLAN scenarios,
      devices may implement (partial) GTK rekeying on
      the device to avoid waking up the host for it.
      
      In order to successfully go through GTK rekeying,
      the KEK, KCK and the replay counter are required.
      
      Add API to let the supplicant hand the parameters
      to the driver which may store it for future GTK
      rekey operations.
      
      Note that, of course, if GTK rekeying is done by
      the device, the EAP frame must not be passed up
      to userspace, instead a rekey event needs to be
      sent to let userspace update its replay counter.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e5497d76
  6. 28 6月, 2011 1 次提交
  7. 02 6月, 2011 1 次提交
  8. 25 5月, 2011 1 次提交
  9. 19 5月, 2011 1 次提交
    • J
      cfg80211: Use consistent BSS matching between scan and sme · ed9d0102
      Jouni Malinen 提交于
      cfg80211 scan code adds separate BSS entries if the same BSS shows up
      on multiple channels. However, sme implementation does not use the
      frequency when fetching the BSS entry. Fix this by adding channel
      information to cfg80211_roamed() and include it in cfg80211_get_bss()
      calls.
      
      Please note that drivers using cfg80211_roamed() need to be modified to
      fully implement this fix. This commit includes only minimal changes to
      avoid compilation issues; it maintains the old (broken) behavior for
      most drivers. ath6kl was the only one that I could test, so I updated
      it to provide the operating frequency in the roamed event.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ed9d0102
  10. 17 5月, 2011 3 次提交
  11. 13 5月, 2011 2 次提交
  12. 12 5月, 2011 4 次提交
  13. 06 5月, 2011 2 次提交
  14. 13 4月, 2011 4 次提交
  15. 08 4月, 2011 1 次提交
  16. 31 3月, 2011 1 次提交
  17. 22 3月, 2011 1 次提交
  18. 12 3月, 2011 1 次提交
  19. 02 3月, 2011 1 次提交
  20. 22 1月, 2011 1 次提交
    • B
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf 提交于
      Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
      IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
      channel numbers in the 2GHz and 5GHz band we can't map from channel to
      frequency without knowing the band. This is no problem as in most contexts we
      know the band. In places where we don't know the band (and WEXT compatibility)
      we assume the 2GHz band for channels below 14.
      
      This patch does not implement all channel to frequency mappings defined in
      802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
      channels as well as 802.11y channels have been omitted.
      
      The following drivers have been updated to reflect the API changes:
      iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
      The drivers have been compile-tested only.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      59eb21a6
  21. 11 1月, 2011 1 次提交
  22. 21 12月, 2010 3 次提交
  23. 17 12月, 2010 2 次提交
    • L
      cfg80211: fix null pointer dereference with a custom regulatory request · 2784fe91
      Luis R. Rodriguez 提交于
      Once we moved the core regulatory request to the queue and let
      the scheduler process it last_request will have been left NULL
      until the schedular decides to process the first request. When
      this happens and we are loading a driver with a custom regulatory
      request like all Atheros drivers we end up with a NULL pointer
      dereference. We fix this by checking if the request was a
      custom one.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      IP: [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      PGD 71f91067 PUD 712b2067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/firmware/2-1/loading
      CPU 0
      Modules linked in: ath9k_htc(+) ath9k_common ath9k_hw ath <etc>
      Pid: 3094, comm: insmod Tainted: G        W   2.6.37-rc5-wl #16 INVALID/28427ZQ
      RIP: 0010:[<ffffffffa016de87>]  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      RSP: 0018:ffff88007045db78  EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffffffffa047d9a0 RCX: ffff88007045dbd0
      RDX: 0000000000004e20 RSI: 000000000024cde0 RDI: ffff8800700483e0
      RBP: ffff88007045db98 R08: ffffffffa02f5b40 R09: 0000000000000001
      R10: 000000000000000e R11: 0000000000000001 R12: 0000000000000000
      R13: ffff88007004e3b0 R14: 0000000000000000 R15: ffff880070048340
      FS:  00007f635a707700(0000) GS:ffff880077400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000004 CR3: 00000000708a9000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process insmod (pid: 3094, threadinfo ffff88007045c000, task ffff8800713e3ec0)
      Stack:
       ffffffffa047d9a0 0000000000000000 ffff88007004e3b0 0000000000000000
       ffff88007045dc08 ffffffffa016e147 000000007045dc08 0000000000000002
       ffff8800700483e0 ffffffffa02f5b40 ffff88007045dbd8 0000000000000000
      Call Trace:
       [<ffffffffa016e147>] wiphy_apply_custom_regulatory+0x137/0x1d0 [cfg80211]
       [<ffffffffa047a690>] ? ath9k_reg_notifier+0x0/0x50 [ath9k_htc]
       [<ffffffffa02f47f7>] ath_regd_init+0x347/0x430 [ath]
       [<ffffffffa047b1f5>] ath9k_htc_probe_device+0x6c5/0x960 [ath9k_htc]
       [<ffffffffa0472a2c>] ath9k_htc_hw_init+0xc/0x30 [ath9k_htc]
       [<ffffffffa04747e6>] ath9k_hif_usb_probe+0x216/0x3b0 [ath9k_htc]
       [<ffffffffa03bb6bc>] usb_probe_interface+0x10c/0x210 [usbcore]
       [<ffffffff812aec26>] driver_probe_device+0x96/0x1c0
       [<ffffffff812aedf3>] __driver_attach+0xa3/0xb0
       [<ffffffff812aed50>] ? __driver_attach+0x0/0xb0
       [<ffffffff812adaae>] bus_for_each_dev+0x5e/0x90
       [<ffffffff812ae8c9>] driver_attach+0x19/0x20
       [<ffffffff812ae438>] bus_add_driver+0x168/0x320
       [<ffffffff812af071>] driver_register+0x71/0x140
       [<ffffffff811fc4a8>] ? __raw_spin_lock_init+0x38/0x70
       [<ffffffffa03ba39c>] usb_register_driver+0xdc/0x190 [usbcore]
       [<ffffffffa03a2000>] ? ath9k_htc_init+0x0/0x4f [ath9k_htc]
       [<ffffffffa047499e>] ath9k_hif_usb_init+0x1e/0x20 [ath9k_htc]
       [<ffffffffa03a202b>] ath9k_htc_init+0x2b/0x4f [ath9k_htc]
       [<ffffffff8100212f>] do_one_initcall+0x3f/0x180
       [<ffffffff8109ef5b>] sys_init_module+0xbb/0x200
       [<ffffffff8100bf52>] system_call_fastpath+0x16/0x1b
      Code: <etc, who cares>
      RIP  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
       RSP <ffff88007045db78>
      CR2: 0000000000000004
      ---[ end trace 79e4193601c8b713 ]---
      Reported-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2784fe91
    • J
      nl80211: Add notification for dropped Deauth/Disassoc · cf4e594e
      Jouni Malinen 提交于
      Add a new notification to indicate that a received, unprotected
      Deauthentication or Disassociation frame was dropped due to
      management frame protection being in use. This notification is
      needed to allow user space (e.g., wpa_supplicant) to implement
      SA Query procedure to recover from association state mismatch
      between an AP and STA.
      
      This is needed to avoid getting stuck in non-working state when MFP
      (IEEE 802.11w) is used and a protected Deauthentication or
      Disassociation frame is dropped for any reason. After that, the
      station would silently discard any unprotected Deauthentication or
      Disassociation frame that could be indicating that the AP does not
      have association for the STA (when the Reason Code would be 6 or 7).
      IEEE Std 802.11w-2009, 11.13 describes this recovery mechanism.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cf4e594e
  24. 16 12月, 2010 1 次提交
  25. 14 12月, 2010 1 次提交