1. 23 12月, 2011 5 次提交
    • G
      Bluetooth: Remove lock from inquiry_cache · 460da45d
      Gustavo F. Padovan 提交于
      It was never used, so removing it.
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      460da45d
    • B
      Bluetooth: Add MITM mechanism to LE-SMP · 2b64d153
      Brian Gix 提交于
      To achive Man-In-The-Middle (MITM) level security with Low Energy,
      we have to enable User Passkey Comparison.  This commit modifies the
      hard-coded JUST-WORKS pairing mechanism to support query via the MGMT
      interface of Passkey comparison and User Confirmation.
      Signed-off-by: NBrian Gix <bgix@codeaurora.org>
      Acked-by: Marcel Holtmann<marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      2b64d153
    • U
      Bluetooth: Fix deadlocks with sock lock and L2CAP timers locks · 371fd835
      Ulisses Furquim 提交于
      When cancelling a delayed work (timer) in L2CAP we can not sleep holding
      the sock mutex otherwise we might deadlock with an L2CAP timer handler.
      This is possible because RX/TX and L2CAP timers run in different workqueues.
      The scenario below illustrates the problem. Thus we are now avoiding to
      sleep on the timers locks.
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.1.0-05270-ga978dc7-dirty #239
       -------------------------------------------------------
       kworker/1:1/873 is trying to acquire lock:
        (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
      
       but task is already holding lock:
        ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 ((&(&chan->chan_timer)->work)){+.+...}:
              [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
              [<ffffffff8106b903>] validate_chain+0x613/0x790
              [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
              [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
              [<ffffffff81052a6f>] wait_on_work+0x4f/0x160
              [<ffffffff81052ca3>] __cancel_work_timer+0x73/0x80
              [<ffffffff81052cbd>] cancel_delayed_work_sync+0xd/0x10
              [<ffffffffa002f2ed>] l2cap_chan_connect+0x22d/0x470 [bluetooth]
              [<ffffffffa002fb51>] l2cap_sock_connect+0xb1/0x140 [bluetooth]
              [<ffffffff8130811b>] kernel_connect+0xb/0x10
              [<ffffffffa00cf98a>] rfcomm_session_create+0x12a/0x1c0 [rfcomm]
              [<ffffffffa00cfbe7>] __rfcomm_dlc_open+0x1c7/0x240 [rfcomm]
              [<ffffffffa00d07c2>] rfcomm_dlc_open+0x42/0x70 [rfcomm]
              [<ffffffffa00d3b03>] rfcomm_sock_connect+0x103/0x150 [rfcomm]
              [<ffffffff8130bd7e>] sys_connect+0xae/0xc0
              [<ffffffff813368d2>] compat_sys_socketcall+0xb2/0x220
              [<ffffffff813b2089>] sysenter_dispatch+0x7/0x30
      
       -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}:
              [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0
              [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
              [<ffffffff8106b903>] validate_chain+0x613/0x790
              [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
              [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
              [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0
              [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
              [<ffffffff81051ae4>] process_one_work+0x184/0x450
              [<ffffffff8105276e>] worker_thread+0x15e/0x340
              [<ffffffff81057bb6>] kthread+0x96/0xa0
              [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock((&(&chan->chan_timer)->work));
                                      lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
                                      lock((&(&chan->chan_timer)->work));
         lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
      
        *** DEADLOCK ***
      
       2 locks held by kworker/1:1/873:
        #0:  (events){.+.+.+}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450
        #1:  ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450
      
       stack backtrace:
       Pid: 873, comm: kworker/1:1 Not tainted 3.1.0-05270-ga978dc7-dirty #239
       Call Trace:
        [<ffffffff813a0f6e>] print_circular_bug+0xd2/0xe3
        [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0
        [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
        [<ffffffff8106b903>] validate_chain+0x613/0x790
        [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
        [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0
        [<ffffffff8106ea30>] ? lock_release_nested+0x100/0x110
        [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0
        [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
        [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
        [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0
        [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
        [<ffffffff81051a86>] ? process_one_work+0x126/0x450
        [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
        [<ffffffff81051ae4>] process_one_work+0x184/0x450
        [<ffffffff81051a86>] ? process_one_work+0x126/0x450
        [<ffffffffa002ce70>] ? l2cap_security_cfm+0x4e0/0x4e0 [bluetooth]
        [<ffffffff8105276e>] worker_thread+0x15e/0x340
        [<ffffffff81052610>] ? manage_workers+0x110/0x110
        [<ffffffff81057bb6>] kthread+0x96/0xa0
        [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10
        [<ffffffff813af69d>] ? retint_restore_args+0xe/0xe
        [<ffffffff81057b20>] ? __init_kthread_worker+0x70/0x70
        [<ffffffff813b1ef0>] ? gs_change+0xb/0xb
      Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      371fd835
    • U
      Bluetooth: Make HCI call directly into SCO and L2CAP event functions · 686ebf28
      Ulisses Furquim 提交于
      The struct hci_proto and all related register/unregister and dispatching
      code was removed. HCI core code now call directly the SCO and L2CAP
      event functions.
      Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      686ebf28
    • A
      Bluetooth: Remove magic numbers from le scan cmd · 68a8aea4
      Andrei Emeltchenko 提交于
      Make code readable by removing magic numbers.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      68a8aea4
  2. 21 12月, 2011 6 次提交
  3. 20 12月, 2011 2 次提交
  4. 19 12月, 2011 21 次提交
  5. 17 12月, 2011 4 次提交
  6. 16 12月, 2011 2 次提交
    • L
      cfg80211: allow following country IE power for custom regdom cards · 061acaae
      Luis R. Rodriguez 提交于
      By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the
      wiphy to adjust itself to the country IE power information if the
      card had no regulatory data but we had no way to tell cfg80211 that if
      the card also had its own custom regulatory domain (these are typically
      custom world regulatory domains) that we want to follow the country IE's
      noted values for power for each channel. We add support for this and
      document it.
      
      This is not a critical fix but a performance optimization for cards
      with custom regulatory domains that associate to an AP with sends
      out country IEs with a higher EIRP than the one on the custom
      regulatory domain. In practice the only driver affected right now
      are the Atheros drivers as they are the only drivers using both
      WIPHY_FLAG_STRICT_REGULATORY and WIPHY_FLAG_CUSTOM_REGULATORY --
      used on cards that have an Atheros world regulatory domain. Cards
      that have been programmed to follow a country specifically will not
      follow the country IE power. So although not a stable fix distributions
      should consider cherry picking this.
      
      Cc: compat@orbit-lab.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com>
      Reported-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      061acaae
    • J
      cfg80211: validate nl80211 station handling better · bdd90d5e
      Johannes Berg 提交于
      The nl80211 station handling code is a bit messy
      and doesn't do a lot of validation. It seems like
      this could be an issue for drivers that don't use
      mac80211 to validate everything.
      
      As cfg80211 doesn't keep station state, move the
      validation of allowing supported_rates to change
      for TDLS only in station mode to mac80211.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bdd90d5e