1. 12 5月, 2011 5 次提交
  2. 11 5月, 2011 1 次提交
  3. 06 5月, 2011 2 次提交
    • J
      nl80211/cfg80211: WoWLAN support · ff1b6e69
      Johannes Berg 提交于
      This is based on (but now quite far from) the
      original work from Luis and Eliad. Add support
      for configuring WoWLAN triggers, and getting
      the configuration out again. Changes from the
      original patchset are too numerous to list,
      but one important change needs highlighting:
      the suspend() callback is passed NULL for the
      trigger configuration if userspace has not
      configured WoWLAN at all.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ff1b6e69
    • J
      nl80211: Fix set_key regression with some drivers · 0e579d6a
      Jouni Malinen 提交于
      Commit dbd2fd65 added a mechanism for
      user space to indicate whether a default key is being configured for
      only unicast or only multicast frames instead of all frames. This
      commit added a driver capability flag for indicating whether separate
      default keys are supported and validation of the set_key command based
      on that capability.
      
      However, this single capability flag is not enough to cover possible
      difference based on mode (AP/IBSS/STA) and the way this change was
      introduced resulted in a regression with drivers that do not indicate
      the new capability (i.e.., more or less any non-mac80211 driver using
      cfg80211) when using a recent wpa_supplicant snapshot.
      
      Fix the regression by removing the new check which is not strictly
      speaking needed. The new separate default key functionality is needed
      only for RSN IBSS which has a separate capability indication.
      
      Cc: stable@kernel.org
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0e579d6a
  4. 27 4月, 2011 1 次提交
  5. 26 4月, 2011 1 次提交
  6. 13 4月, 2011 7 次提交
  7. 08 4月, 2011 3 次提交
  8. 31 3月, 2011 1 次提交
  9. 29 3月, 2011 2 次提交
  10. 12 3月, 2011 1 次提交
  11. 10 3月, 2011 1 次提交
  12. 02 3月, 2011 1 次提交
  13. 22 2月, 2011 1 次提交
    • D
      fix cfg80211_wext_siwfreq lock ordering... · 4f919a3b
      Daniel J Blueman 提交于
      I previously managed to reproduce a hang while scanning wireless
      channels (reproducible with airodump-ng hopping channels); subsequent
      lockdep instrumentation revealed a lock ordering issue.
      
      Without knowing the design intent, it looks like the locks should be
      taken in reverse order; please comment.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.38-rc5-341cd #4
      -------------------------------------------------------
      airodump-ng/15445 is trying to acquire lock:
       (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffff816b1266>]
      cfg80211_wext_siwfreq+0xc6/0x100
      
      but task is already holding lock:
       (&wdev->mtx){+.+.+.}, at: [<ffffffff816b125c>] cfg80211_wext_siwfreq+0xbc/0x100
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&wdev->mtx){+.+.+.}:
             [<ffffffff810a79d6>] lock_acquire+0xc6/0x280
             [<ffffffff816d6bce>] mutex_lock_nested+0x6e/0x4b0
             [<ffffffff81696080>] cfg80211_netdev_notifier_call+0x430/0x5f0
             [<ffffffff8109351b>] notifier_call_chain+0x8b/0x100
             [<ffffffff810935b1>] raw_notifier_call_chain+0x11/0x20
             [<ffffffff81576d92>] call_netdevice_notifiers+0x32/0x60
             [<ffffffff815771a4>] __dev_notify_flags+0x34/0x80
             [<ffffffff81577230>] dev_change_flags+0x40/0x70
             [<ffffffff8158587c>] do_setlink+0x1fc/0x8d0
             [<ffffffff81586042>] rtnl_setlink+0xf2/0x140
             [<ffffffff81586923>] rtnetlink_rcv_msg+0x163/0x270
             [<ffffffff8159d741>] netlink_rcv_skb+0xa1/0xd0
             [<ffffffff815867b0>] rtnetlink_rcv+0x20/0x30
             [<ffffffff8159d39a>] netlink_unicast+0x2ba/0x300
             [<ffffffff8159dd57>] netlink_sendmsg+0x267/0x3e0
             [<ffffffff8155e364>] sock_sendmsg+0xe4/0x110
             [<ffffffff8155f3a3>] sys_sendmsg+0x253/0x3b0
             [<ffffffff81003192>] system_call_fastpath+0x16/0x1b
      
      -> #0 (&rdev->devlist_mtx){+.+.+.}:
             [<ffffffff810a7222>] __lock_acquire+0x1622/0x1d10
             [<ffffffff810a79d6>] lock_acquire+0xc6/0x280
             [<ffffffff816d6bce>] mutex_lock_nested+0x6e/0x4b0
             [<ffffffff816b1266>] cfg80211_wext_siwfreq+0xc6/0x100
             [<ffffffff816b2fad>] ioctl_standard_call+0x5d/0xd0
             [<ffffffff816b3223>] T.808+0x163/0x170
             [<ffffffff816b326a>] wext_handle_ioctl+0x3a/0x90
             [<ffffffff815798d2>] dev_ioctl+0x6f2/0x830
             [<ffffffff8155cf3d>] sock_ioctl+0xfd/0x290
             [<ffffffff8117dffd>] do_vfs_ioctl+0x9d/0x590
             [<ffffffff8117e53a>] sys_ioctl+0x4a/0x80
             [<ffffffff81003192>] system_call_fastpath+0x16/0x1b
      
      other info that might help us debug this:
      
      2 locks held by airodump-ng/15445:
       #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81586782>] rtnl_lock+0x12/0x20
       #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffff816b125c>]
      cfg80211_wext_siwfreq+0xbc/0x100
      
      stack backtrace:
      Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
      Call Trace:
       [<ffffffff810a3f0a>] ? print_circular_bug+0xfa/0x100
       [<ffffffff810a7222>] ? __lock_acquire+0x1622/0x1d10
       [<ffffffff810a1f99>] ? trace_hardirqs_off_caller+0x29/0xc0
       [<ffffffff810a79d6>] ? lock_acquire+0xc6/0x280
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff810a31d7>] ? mark_held_locks+0x67/0x90
       [<ffffffff816d6bce>] ? mutex_lock_nested+0x6e/0x4b0
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff810a31d7>] ? mark_held_locks+0x67/0x90
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff816b2fad>] ? ioctl_standard_call+0x5d/0xd0
       [<ffffffff8157818b>] ? __dev_get_by_name+0x9b/0xc0
       [<ffffffff816b2f50>] ? ioctl_standard_call+0x0/0xd0
       [<ffffffff816b3223>] ? T.808+0x163/0x170
       [<ffffffff8112ddf2>] ? might_fault+0x72/0xd0
       [<ffffffff816b326a>] ? wext_handle_ioctl+0x3a/0x90
       [<ffffffff8112de3b>] ? might_fault+0xbb/0xd0
       [<ffffffff815798d2>] ? dev_ioctl+0x6f2/0x830
       [<ffffffff810a1bae>] ? put_lock_stats+0xe/0x40
       [<ffffffff810a1c8c>] ? lock_release_holdtime+0xac/0x150
       [<ffffffff8155cf3d>] ? sock_ioctl+0xfd/0x290
       [<ffffffff8117dffd>] ? do_vfs_ioctl+0x9d/0x590
       [<ffffffff8116c8ff>] ? fget_light+0x1df/0x3c0
       [<ffffffff8117e53a>] ? sys_ioctl+0x4a/0x80
       [<ffffffff81003192>] ? system_call_fastpath+0x16/0x1b
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4f919a3b
  14. 04 2月, 2011 1 次提交
    • J
      cfg80211: Fix power save state after interface type change · bf6a0579
      Juuso Oikarinen 提交于
      Currently cfg80211 only configures the PSM state to the driver upon creation
      of a new virtual interface, but not after interface type change. The mac80211
      on the other hand reinitializes its sdata structure every time the interface
      type is changed, losing the PSM configuration.
      
      Hence, if the interface type is changed to, say, ad-hoc and then back to
      managed, "iw wlan0 get power_save" will claim that PSM is enabled, when in
      fact on mac80211 level it is not.
      
      Fix this in cfg80211 by configuring the PSM state to the driver each time
      the interface is brought up instead of just when the interface is created.
      Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bf6a0579
  15. 29 1月, 2011 2 次提交
  16. 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
  17. 21 1月, 2011 1 次提交
    • D
      kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT · 6a108a14
      David Rientjes 提交于
      The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
      is used to configure any non-standard kernel with a much larger scope than
      only small devices.
      
      This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
      references to the option throughout the kernel.  A new CONFIG_EMBEDDED
      option is added that automatically selects CONFIG_EXPERT when enabled and
      can be used in the future to isolate options that should only be
      considered for embedded systems (RISC architectures, SLOB, etc).
      
      Calling the option "EXPERT" more accurately represents its intention: only
      expert users who understand the impact of the configuration changes they
      are making should enable it.
      Reviewed-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Greg KH <gregkh@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Robin Holt <holt@sgi.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a108a14
  18. 05 1月, 2011 1 次提交
  19. 21 12月, 2010 5 次提交
  20. 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