1. 05 8月, 2009 8 次提交
    • J
      cfg80211: lower dynamic PS timeout to 100ms · 75e6c3b7
      Johannes Berg 提交于
      The default of 500ms is pretty high, and leads
      to the device being awake at least 50% of the
      time under such light traffic conditions as a
      simple 1 second interval ping. Reduce to just
      100ms -- it should have a similar effect while
      providing a better sleep time.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Reviewed-by: NKalle Valo <kalle.valo@iki.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      75e6c3b7
    • L
      cfg80211: enable country IE support to all cfg80211 drivers · 8b19e6ca
      Luis R. Rodriguez 提交于
      Since the bss is always set now once we are connected, if the
      bss has its own information element we refer to it and pass that
      instead of relying on mac80211's parsing.
      
      Now all cfg80211 drivers get country IE support, automatically and
      we reduce the call overhead that we had on mac80211 which called this
      upon every beacon and instead now call this only upon a successfull
      connection by a STA on cfg80211.
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8b19e6ca
    • L
      cfg80211: decouple regulatory variables from cfg80211_mutex · abc7381b
      Luis R. Rodriguez 提交于
      We change regulatory code to be protected by its own regulatory
      mutex and alleviate cfg80211_mutex to only be used to protect
      cfg80211_rdev_list, the registered device list.
      
      By doing this we will be able to work on regulatory core components
      without having to have hog up the cfg80211_mutex. An example here is
      we no longer need to use the cfg80211_mutex during driver specific
      wiphy_apply_custom_regulatory(). We also no longer need it for the
      the country IE regulatory hint; by doing so we end up curing this
      new lockdep warning:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.31-rc4-wl #12
      -------------------------------------------------------
      phy1/1709 is trying to acquire lock:
       (cfg80211_mutex){+.+.+.}, at: [<ffffffffa00af852>] regulatory_hint_11d+0x32/0x3f0 [cfg80211]
      
      but task is already holding lock:
       (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #3 (&ifmgd->mtx){+.+.+.}:
             [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
             [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
             [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
             [<ffffffffa0141bb8>] ieee80211_mgd_auth+0x108/0x1f0 [mac80211]
             [<ffffffffa0148563>] ieee80211_auth+0x13/0x20 [mac80211]
             [<ffffffffa00bc3a1>] __cfg80211_mlme_auth+0x1b1/0x2a0 [cfg80211]
             [<ffffffffa00bc516>] cfg80211_mlme_auth+0x86/0xc0 [cfg80211]
             [<ffffffffa00b368d>] nl80211_authenticate+0x21d/0x230 [cfg80211]
             [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
             [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
             [<ffffffff814169d9>] genl_rcv+0x29/0x40
             [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
             [<ffffffff81416514>] netlink_sendmsg+0x214/0x300
             [<ffffffff813e4407>] sock_sendmsg+0x107/0x130
             [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
             [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      -> #2 (&wdev->mtx){+.+.+.}:
             [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
             [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
             [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
             [<ffffffffa00ab304>] cfg80211_netdev_notifier_call+0x1a4/0x390 [cfg80211]
             [<ffffffff814f3dff>] notifier_call_chain+0x3f/0x80
             [<ffffffff81075a91>] raw_notifier_call_chain+0x11/0x20
             [<ffffffff813f665a>] dev_open+0x10a/0x120
             [<ffffffff813f59bd>] dev_change_flags+0x9d/0x1e0
             [<ffffffff8144eb6e>] devinet_ioctl+0x6fe/0x760
             [<ffffffff81450204>] inet_ioctl+0x94/0xc0
             [<ffffffff813e25fa>] sock_ioctl+0x6a/0x290
             [<ffffffff8111e911>] vfs_ioctl+0x31/0xa0
             [<ffffffff8111ea9a>] do_vfs_ioctl+0x8a/0x5c0
             [<ffffffff8111f069>] sys_ioctl+0x99/0xa0
             [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      -> #1 (&rdev->mtx){+.+.+.}:
             [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
             [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
             [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
             [<ffffffffa00ac4d0>] cfg80211_get_dev_from_ifindex+0x60/0x90 [cfg80211]
             [<ffffffffa00b21ff>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211]
             [<ffffffffa00b51eb>] nl80211_set_interface+0x3b/0x260 [cfg80211]
             [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
             [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
             [<ffffffff814169d9>] genl_rcv+0x29/0x40
             [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
             [<ffffffff81416514>] netlink_sendmsg+0x214/0x300
             [<ffffffff813e4407>] sock_sendmsg+0x107/0x130
             [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
             [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      other info that might help us debug this:
      
      3 locks held by phy1/1709:
       #0:  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
       #1:  (&ifmgd->work){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
       #2:  (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
      Reported-by: NReinette Chatre <reinette.chatre@intel.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      abc7381b
    • L
      cfg80211: do not iterate over rdev list on country IE hint · 4b44c8bc
      Luis R. Rodriguez 提交于
      Simplify the country IE hint code by just bailing out if
      a previous country IE has been issued. We currently just trust
      the first AP we connect to on any card. The idea was to perform
      conflict resolution within this routine but since we can no longer
      iterate over the registered device list here we leave conflict
      resolution to be dealt with at a later time on the workqueue.
      
      This code has no functional changes other than saving us an
      interation over the registered device list when a second card
      is connected, or you unplug and connect the same one, and a
      country IE is received. This would have been done upon every
      beacon received.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4b44c8bc
    • L
      cfg80211: use goto out on country IE reg hint failure · 9828b017
      Luis R. Rodriguez 提交于
      This has no functional changes.
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9828b017
    • J
      cfg80211: fix NETDEV_UNREGISTER notifier · e40cbdac
      Johannes Berg 提交于
      It's possible to get the NETDEV_UNREGISTER callback multiple
      times (see net/core/dev.c:netdev_wait_allrefs) and this will
      completely mess up our cleanup code. To avoid that, clean up
      only when the interface is still on the wiphy interface list
      from which it's removed on the first NETDEV_UNREGISTER call.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e40cbdac
    • J
      cfg80211: keep track of current_bss for userspace SME · df7fc0f9
      Johannes Berg 提交于
      When a userspace SME is active, we're currently not
      keeping track of the BSS properly for reporting the
      current link and for internal use. Additionally, it
      looks like there is a possible BSS leak in that the
      BSS never gets removed from auth_bsses[]. To fix it,
      pass the BSS struct to __cfg80211_connect_result in
      this case.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      df7fc0f9
    • L
  2. 30 7月, 2009 7 次提交
  3. 28 7月, 2009 2 次提交
    • H
      cfg80211: increase scan result expire time · 09f97e0f
      Helmut Schaa 提交于
      Using background scanning in mac80211 the time a scan needs to
      finish can exceed 10 seconds. Hence, increase the scan results
      expire time to 15 seconds which should be sufficient.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      09f97e0f
    • J
      cfg80211: make aware of net namespaces · 463d0183
      Johannes Berg 提交于
      In order to make cfg80211/nl80211 aware of network namespaces,
      we have to do the following things:
      
       * del_virtual_intf method takes an interface index rather
         than a netdev pointer - simply change this
      
       * nl80211 uses init_net a lot, it changes to use the sender's
         network namespace
      
       * scan requests use the interface index, hold a netdev pointer
         and reference instead
      
       * we want a wiphy and its associated virtual interfaces to be
         in one netns together, so
          - we need to be able to change ns for a given interface, so
            export dev_change_net_namespace()
          - for each virtual interface set the NETIF_F_NETNS_LOCAL
            flag, and clear that flag only when the wiphy changes ns,
            to disallow breaking this invariant
      
       * when a network namespace goes away, we need to reparent the
         wiphy to init_net
      
       * cfg80211 users that support creating virtual interfaces must
         create them in the wiphy's namespace, currently this affects
         only mac80211
      
      The end result is that you can now switch an entire wiphy into
      a different network namespace with the new command
      	iw phy#<idx> set netns <pid>
      and all virtual interfaces will follow (or the operation fails).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      463d0183
  4. 25 7月, 2009 19 次提交
  5. 22 7月, 2009 2 次提交
    • C
      cfg80211: double free in __cfg80211_scan_done · 9e81eccf
      Christian Lamparter 提交于
      This patch fixes a double free corruption in __cfg80211_scan_done:
      
       ================================================
       BUG kmalloc-512: Object already free
       ------------------------------------------------
      
       INFO: Allocated in load_elf_binary+0x18b/0x19af age=6
       INFO: Freed in load_elf_binary+0x104e/0x19af age=5
       INFO: Slab 0xffffea0001bae4c0 objects=14 used=7
       INFO: Object 0xffff88007e8a9918 @offset=6424 fp=0xffff88007e8a9488
      
       Bytes b4 0xffff88007e8a9908:  00 00 00 00 00 00 00 00 5a 5a
       [...]
       Pid: 28705, comm: rmmod Tainted: P         C 2.6.31-rc2-wl #1
       Call Trace:
        [<ffffffff810da9f4>] print_trailer+0x14e/0x16e
        [<ffffffff810daa56>] object_err+0x42/0x61
        [<ffffffff810dbcd9>] __slab_free+0x2af/0x396
        [<ffffffffa0ec9694>] ? wiphy_unregister+0x92/0x142 [cfg80211]
        [<ffffffff810dd5e3>] kfree+0x13c/0x17a
        [<ffffffffa0ec9694>] ? wiphy_unregister+0x92/0x142 [cfg80211]
        [<ffffffffa0ec9694>] wiphy_unregister+0x92/0x142 [cfg80211]
        [<ffffffffa0eed163>] ieee80211_unregister_hw+0xc8/0xff [mac80211]
        [<ffffffffa0f3fbc8>] p54_unregister_common+0x31/0x66 [p54common]
        [...]
       FIX kmalloc-512: Object at 0xffff88007e8a9918 not freed
      
      The code path which leads to the *funny* double free:
      
             request = rdev->scan_req;
             dev = dev_get_by_index(&init_net, request->ifidx);
      	/*
      	 * the driver was unloaded recently and
      	 * therefore dev_get_by_index will return NULL!
      	 */
              if (!dev)
                      goto out;
      	[...]
      	rdev->scan_req = NULL; /* not executed... */
      	[...]
       out:
              kfree(request);
      Signed-off-by: NChristian Lamparter <chunkeey@web.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9e81eccf
    • N
      nl80211: Memory leak fixed · 6c95e2a2
      Niko Jokinen 提交于
      Potential memory leak via msg pointer in nl80211_get_key() function.
      Signed-off-by: NNiko Jokinen <ext-niko.k.jokinen@nokia.com>
      Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6c95e2a2
  6. 15 7月, 2009 2 次提交
    • J
      net/compat/wext: send different messages to compat tasks · 1dacc76d
      Johannes Berg 提交于
      Wireless extensions have the unfortunate problem that events
      are multicast netlink messages, and are not independent of
      pointer size. Thus, currently 32-bit tasks on 64-bit platforms
      cannot properly receive events and fail with all kinds of
      strange problems, for instance wpa_supplicant never notices
      disassociations, due to the way the 64-bit event looks (to a
      32-bit process), the fact that the address is all zeroes is
      lost, it thinks instead it is 00:00:00:00:01:00.
      
      The same problem existed with the ioctls, until David Miller
      fixed those some time ago in an heroic effort.
      
      A different problem caused by this is that we cannot send the
      ASSOCREQIE/ASSOCRESPIE events because sending them causes a
      32-bit wpa_supplicant on a 64-bit system to overwrite its
      internal information, which is worse than it not getting the
      information at all -- so we currently resort to sending a
      custom string event that it then parses. This, however, has a
      severe size limitation we are frequently hitting with modern
      access points; this limitation would can be lifted after this
      patch by sending the correct binary, not custom, event.
      
      A similar problem apparently happens for some other netlink
      users on x86_64 with 32-bit tasks due to the alignment for
      64-bit quantities.
      
      In order to fix these problems, I have implemented a way to
      send compat messages to tasks. When sending an event, we send
      the non-compat event data together with a compat event data in
      skb_shinfo(main_skb)->frag_list. Then, when the event is read
      from the socket, the netlink code makes sure to pass out only
      the skb that is compatible with the task. This approach was
      suggested by David Miller, my original approach required
      always sending two skbs but that had various small problems.
      
      To determine whether compat is needed or not, I have used the
      MSG_CMSG_COMPAT flag, and adjusted the call path for recv and
      recvfrom to include it, even if those calls do not have a cmsg
      parameter.
      
      I have not solved one small part of the problem, and I don't
      think it is necessary to: if a 32-bit application uses read()
      rather than any form of recvmsg() it will still get the wrong
      (64-bit) event. However, neither do applications actually do
      this, nor would it be a regression.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1dacc76d
    • J
      wext: optimise, comment and fix event sending · 4f45b2cd
      Johannes Berg 提交于
      The current function for sending events first allocates the
      event stream buffer, and then an skb to copy the event stream
      into. This can be done in one go. Also, the current function
      leaks kernel data to userspace in a 4 uninitialised bytes,
      initialise those explicitly. Finally also add a few useful
      comments, as opposed to the current comments.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f45b2cd