1. 15 7月, 2008 3 次提交
    • M
      [Bluetooth] Export details about authentication requirements · 40be492f
      Marcel Holtmann 提交于
      With the Simple Pairing support, the authentication requirements are
      an explicit setting during the bonding process. Track and enforce the
      requirements and allow higher layers like L2CAP and RFCOMM to increase
      them if needed.
      
      This patch introduces a new IOCTL that allows to query the current
      authentication requirements. It is also possible to detect Simple
      Pairing support in the kernel this way.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      40be492f
    • M
      [Bluetooth] Disconnect when encryption gets disabled · 9719f8af
      Marcel Holtmann 提交于
      The Bluetooth specification allows to enable or disable the encryption
      of an ACL link at any time by either the peer or the remote device. If
      a L2CAP or RFCOMM connection requested an encrypted link, they will now
      disconnect that link if the encryption gets disabled. Higher protocols
      that don't care about encryption (like SDP) are not affected.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9719f8af
    • M
      [Bluetooth] Enforce security for outgoing RFCOMM connections · 77db1980
      Marcel Holtmann 提交于
      Recent tests with various Bluetooth headsets have shown that some of
      them don't enforce authentication and encryption when connecting. All
      of them leave it up to the host stack to enforce it. Non of them should
      allow unencrypted connections, but that is how it is. So in case the
      link mode settings require authentication and/or encryption it will now
      also be enforced on outgoing RFCOMM connections. Previously this was
      only done for incoming connections.
      
      This support has a small drawback from a protocol level point of view
      since the host stack can't really tell with 100% certainty if a remote
      side is already authenticated or not. So if both sides are configured
      to enforce authentication it will be requested twice. Most Bluetooth
      chips are caching this information and thus no extra authentication
      procedure has to be triggered over-the-air, but it can happen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      77db1980
  2. 29 5月, 2008 1 次提交
    • A
      bluetooth: fix locking bug in the rfcomm socket cleanup handling · 4c8411f8
      Arjan van de Ven 提交于
      in net/bluetooth/rfcomm/sock.c, rfcomm_sk_state_change() does the
      following operation:
      
              if (parent && sock_flag(sk, SOCK_ZAPPED)) {
                      /* We have to drop DLC lock here, otherwise
                       * rfcomm_sock_destruct() will dead lock. */
                      rfcomm_dlc_unlock(d);
                      rfcomm_sock_kill(sk);
                      rfcomm_dlc_lock(d);
              }
      }
      
      which is fine, since rfcomm_sock_kill() will call sk_free() which will call
      rfcomm_sock_destruct() which takes the rfcomm_dlc_lock()... so far so good.
      
      HOWEVER, this assumes that the rfcomm_sk_state_change() function always gets
      called with the rfcomm_dlc_lock() taken. This is the case for all but one
      case, and in that case where we don't have the lock, we do a double unlock
      followed by an attempt to take the lock, which due to underflow isn't
      going anywhere fast.
      
      This patch fixes this by moving the stragling case inside the lock, like
      the other usages of the same call are doing in this code.
      
      This was found with the help of the www.kerneloops.org project, where this
      deadlock was observed 51 times at this point in time:
      http://www.kerneloops.org/search.php?search=rfcomm_sock_destructSigned-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c8411f8
  3. 02 4月, 2008 1 次提交
    • D
      bluetooth : __rfcomm_dlc_close lock fix · 1905f6c7
      Dave Young 提交于
      Lockdep warning will be trigged while rfcomm connection closing.
      
      The locks taken in rfcomm_dev_add:
      rfcomm_dev_lock --> d->lock
      
      In __rfcomm_dlc_close:
      d->lock --> rfcomm_dev_lock (in rfcomm_dev_state_change)
      
      There's two way to fix it, one is in rfcomm_dev_add we first locking
      d->lock then the rfcomm_dev_lock
      
      The other (in this patch), remove the locking of d->lock for
      rfcomm_dev_state_change because just locking "d->state = BT_CLOSED;"
      is enough.
      
      [  295.002046] =======================================================
      [  295.002046] [ INFO: possible circular locking dependency detected ]
      [  295.002046] 2.6.25-rc7 #1
      [  295.002046] -------------------------------------------------------
      [  295.002046] krfcommd/2705 is trying to acquire lock:
      [  295.002046]  (rfcomm_dev_lock){-.--}, at: [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046] 
      [  295.002046] but task is already holding lock:
      [  295.002046]  (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm]
      [  295.002046] 
      [  295.002046] which lock already depends on the new lock.
      [  295.002046] 
      [  295.002046] 
      [  295.002046] the existing dependency chain (in reverse order) is:
      [  295.002046] 
      [  295.002046] -> #1 (&d->lock){--..}:
      [  295.002046]        [<c0149b23>] check_prev_add+0xd3/0x200
      [  295.002046]        [<c0149ce5>] check_prevs_add+0x95/0xe0
      [  295.002046]        [<c0149f6f>] validate_chain+0x23f/0x320
      [  295.002046]        [<c014b7b1>] __lock_acquire+0x1c1/0x760
      [  295.002046]        [<c014c349>] lock_acquire+0x79/0xb0
      [  295.002046]        [<c03d6b99>] _spin_lock+0x39/0x80
      [  295.002046]        [<f89a01c0>] rfcomm_dev_add+0x240/0x360 [rfcomm]
      [  295.002046]        [<f89a047e>] rfcomm_create_dev+0x6e/0xe0 [rfcomm]
      [  295.002046]        [<f89a0823>] rfcomm_dev_ioctl+0x33/0x60 [rfcomm]
      [  295.002046]        [<f899facc>] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm]
      [  295.002046]        [<c0363d38>] sock_ioctl+0x118/0x240
      [  295.002046]        [<c0194196>] vfs_ioctl+0x76/0x90
      [  295.002046]        [<c0194446>] do_vfs_ioctl+0x56/0x140
      [  295.002046]        [<c0194569>] sys_ioctl+0x39/0x60
      [  295.002046]        [<c0104faa>] syscall_call+0x7/0xb
      [  295.002046]        [<ffffffff>] 0xffffffff
      [  295.002046] 
      [  295.002046] -> #0 (rfcomm_dev_lock){-.--}:
      [  295.002046]        [<c0149a84>] check_prev_add+0x34/0x200
      [  295.002046]        [<c0149ce5>] check_prevs_add+0x95/0xe0
      [  295.002046]        [<c0149f6f>] validate_chain+0x23f/0x320
      [  295.002046]        [<c014b7b1>] __lock_acquire+0x1c1/0x760
      [  295.002046]        [<c014c349>] lock_acquire+0x79/0xb0
      [  295.002046]        [<c03d6639>] _read_lock+0x39/0x80
      [  295.002046]        [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]        [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
      [  295.002046]        [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
      [  295.002046]        [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
      [  295.002046]        [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm]
      [  295.002046]        [<c013c18c>] kthread+0x5c/0xa0
      [  295.002046]        [<c0105c07>] kernel_thread_helper+0x7/0x10
      [  295.002046]        [<ffffffff>] 0xffffffff
      [  295.002046] 
      [  295.002046] other info that might help us debug this:
      [  295.002046] 
      [  295.002046] 2 locks held by krfcommd/2705:
      [  295.002046]  #0:  (rfcomm_mutex){--..}, at: [<f899e2eb>] rfcomm_run+0x7b/0x550 [rfcomm]
      [  295.002046]  #1:  (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm]
      [  295.002046] 
      [  295.002046] stack backtrace:
      [  295.002046] Pid: 2705, comm: krfcommd Not tainted 2.6.25-rc7 #1
      [  295.002046]  [<c0128a38>] ? printk+0x18/0x20
      [  295.002046]  [<c014927f>] print_circular_bug_tail+0x6f/0x80
      [  295.002046]  [<c0149a84>] check_prev_add+0x34/0x200
      [  295.002046]  [<c0149ce5>] check_prevs_add+0x95/0xe0
      [  295.002046]  [<c0149f6f>] validate_chain+0x23f/0x320
      [  295.002046]  [<c014b7b1>] __lock_acquire+0x1c1/0x760
      [  295.002046]  [<c014c349>] lock_acquire+0x79/0xb0
      [  295.002046]  [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]  [<c03d6639>] _read_lock+0x39/0x80
      [  295.002046]  [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]  [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]  [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
      [  295.002046]  [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
      [  295.002046]  [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
      [  295.002046]  [<c014abd9>] ? trace_hardirqs_on+0xb9/0x130
      [  295.002046]  [<c03d6e89>] ? _spin_unlock_irqrestore+0x39/0x70
      [  295.002046]  [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm]
      [  295.002046]  [<c03d4559>] ? __sched_text_start+0x229/0x4c0
      [  295.002046]  [<c0120000>] ? cpu_avg_load_per_task+0x20/0x30
      [  295.002046]  [<f899e270>] ? rfcomm_run+0x0/0x550 [rfcomm]
      [  295.002046]  [<c013c18c>] kthread+0x5c/0xa0
      [  295.002046]  [<c013c130>] ? kthread+0x0/0xa0
      [  295.002046]  [<c0105c07>] kernel_thread_helper+0x7/0x10
      [  295.002046]  =======================
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1905f6c7
  4. 14 2月, 2008 1 次提交
  5. 29 1月, 2008 1 次提交
  6. 22 10月, 2007 1 次提交
  7. 18 7月, 2007 1 次提交
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  8. 05 5月, 2007 2 次提交
  9. 26 4月, 2007 2 次提交
  10. 11 2月, 2007 1 次提交
  11. 03 12月, 2006 2 次提交
  12. 16 10月, 2006 1 次提交
  13. 29 9月, 2006 1 次提交
  14. 25 7月, 2006 1 次提交
  15. 13 7月, 2006 1 次提交
  16. 04 7月, 2006 3 次提交
  17. 01 7月, 2006 1 次提交
  18. 21 3月, 2006 1 次提交
  19. 13 2月, 2006 1 次提交
  20. 09 11月, 2005 1 次提交
  21. 29 10月, 2005 1 次提交
  22. 09 10月, 2005 1 次提交
  23. 30 8月, 2005 2 次提交
  24. 06 8月, 2005 1 次提交
  25. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4