1. 15 2月, 2012 1 次提交
    • O
      Bluetooth: silence lockdep warning · b5a30dda
      Octavian Purdila 提交于
      Since bluetooth uses multiple protocols types, to avoid lockdep
      warnings, we need to use different lockdep classes (one for each
      protocol type).
      
      This is already done in bt_sock_create but it misses a couple of cases
      when new connections are created. This patch corrects that to fix the
      following warning:
      
      <4>[ 1864.732366] =======================================================
      <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
      <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
      <4>[ 1864.733883] -------------------------------------------------------
      <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
      <4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.735541]
      <4>[ 1864.735549] but task is already holding lock:
      <4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
      <4>[ 1864.736732]
      <4>[ 1864.736740] which lock already depends on the new lock.
      <4>[ 1864.736750]
      <4>[ 1864.737428]
      <4>[ 1864.737437] the existing dependency chain (in reverse order) is:
      <4>[ 1864.738016]
      <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
      <4>[ 1864.738549]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.738977]        [<c13d35c1>] lock_sock_nested+0x58/0x68
      <4>[ 1864.739411]        [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
      <4>[ 1864.739858]        [<c13d06c3>] __sock_sendmsg+0x50/0x59
      <4>[ 1864.740279]        [<c13d0ea2>] sock_sendmsg+0x94/0xa8
      <4>[ 1864.740687]        [<c13d0ede>] kernel_sendmsg+0x28/0x37
      <4>[ 1864.741106]        [<c14969ca>] rfcomm_send_frame+0x30/0x38
      <4>[ 1864.741542]        [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
      <4>[ 1864.741959]        [<c1498447>] rfcomm_run+0x441/0xb52
      <4>[ 1864.742365]        [<c104f095>] kthread+0x63/0x68
      <4>[ 1864.742742]        [<c14d5182>] kernel_thread_helper+0x6/0xd
      <4>[ 1864.743187]
      <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
      <4>[ 1864.743667]        [<c1061ada>] __lock_acquire+0x988/0xc00
      <4>[ 1864.744100]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.744519]        [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
      <4>[ 1864.744975]        [<c14d303e>] mutex_lock_nested+0x2d/0x36
      <4>[ 1864.745412]        [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.745842]        [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
      <4>[ 1864.746288]        [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
      <4>[ 1864.746737]        [<c13d275d>] sys_socketcall+0x1db/0x422
      <4>[ 1864.747165]        [<c14d42f0>] syscall_call+0x7/0xb
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      b5a30dda
  2. 13 2月, 2012 1 次提交
    • O
      Bluetooth: silence lockdep warning · d22015aa
      Octavian Purdila 提交于
      Since bluetooth uses multiple protocols types, to avoid lockdep
      warnings, we need to use different lockdep classes (one for each
      protocol type).
      
      This is already done in bt_sock_create but it misses a couple of cases
      when new connections are created. This patch corrects that to fix the
      following warning:
      
      <4>[ 1864.732366] =======================================================
      <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
      <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
      <4>[ 1864.733883] -------------------------------------------------------
      <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
      <4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.735541]
      <4>[ 1864.735549] but task is already holding lock:
      <4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
      <4>[ 1864.736732]
      <4>[ 1864.736740] which lock already depends on the new lock.
      <4>[ 1864.736750]
      <4>[ 1864.737428]
      <4>[ 1864.737437] the existing dependency chain (in reverse order) is:
      <4>[ 1864.738016]
      <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
      <4>[ 1864.738549]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.738977]        [<c13d35c1>] lock_sock_nested+0x58/0x68
      <4>[ 1864.739411]        [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
      <4>[ 1864.739858]        [<c13d06c3>] __sock_sendmsg+0x50/0x59
      <4>[ 1864.740279]        [<c13d0ea2>] sock_sendmsg+0x94/0xa8
      <4>[ 1864.740687]        [<c13d0ede>] kernel_sendmsg+0x28/0x37
      <4>[ 1864.741106]        [<c14969ca>] rfcomm_send_frame+0x30/0x38
      <4>[ 1864.741542]        [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
      <4>[ 1864.741959]        [<c1498447>] rfcomm_run+0x441/0xb52
      <4>[ 1864.742365]        [<c104f095>] kthread+0x63/0x68
      <4>[ 1864.742742]        [<c14d5182>] kernel_thread_helper+0x6/0xd
      <4>[ 1864.743187]
      <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
      <4>[ 1864.743667]        [<c1061ada>] __lock_acquire+0x988/0xc00
      <4>[ 1864.744100]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.744519]        [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
      <4>[ 1864.744975]        [<c14d303e>] mutex_lock_nested+0x2d/0x36
      <4>[ 1864.745412]        [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.745842]        [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
      <4>[ 1864.746288]        [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
      <4>[ 1864.746737]        [<c13d275d>] sys_socketcall+0x1db/0x422
      <4>[ 1864.747165]        [<c14d42f0>] syscall_call+0x7/0xb
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      d22015aa
  3. 21 12月, 2011 1 次提交
  4. 03 12月, 2011 1 次提交
  5. 08 11月, 2011 1 次提交
  6. 01 11月, 2011 1 次提交
  7. 18 10月, 2011 1 次提交
  8. 09 7月, 2011 1 次提交
  9. 01 7月, 2011 2 次提交
    • J
      Bluetooth: Add bt_printk · e1447d8d
      Joe Perches 提交于
      Add a local logging function to emit bluetooth specific
      messages.  Using vsprintf extension %pV saves code/text
      space.
      
      Convert the current BT_INFO and BT_ERR macros to use bt_printk.
      Remove __func__ from BT_ERR macro (and the uses).
      Prefix "Bluetooth: " to BT_ERR
      Remove __func__ from BT_DBG as function can be prefixed when
      using dynamic_debug.
      
      With allyesconfig:
      
         text    data     bss     dec     hex filename
       129956    8632   36096  174684   2aa5c drivers/bluetooth/built-in.o.new2
       134402    8632   36064  179098   2bb9a drivers/bluetooth/built-in.o.old
        14778    1012    3408   19198    4afe net/bluetooth/bnep/built-in.o.new2
        15067    1012    3408   19487    4c1f net/bluetooth/bnep/built-in.o.old
       346595   19163   86080  451838   6e4fe net/bluetooth/built-in.o.new2
       353751   19163   86064  458978   700e2 net/bluetooth/built-in.o.old
        18483    1172    4264   23919    5d6f net/bluetooth/cmtp/built-in.o.new2
        18927    1172    4264   24363    5f2b net/bluetooth/cmtp/built-in.o.old
        19237    1172    5152   25561    63d9 net/bluetooth/hidp/built-in.o.new2
        19581    1172    5152   25905    6531 net/bluetooth/hidp/built-in.o.old
        59461    3884   14464   77809   12ff1 net/bluetooth/rfcomm/built-in.o.new2
        61206    3884   14464   79554   136c2 net/bluetooth/rfcomm/built-in.o.old
      
      with x86 defconfig (and just bluetooth):
      
      $ size net/bluetooth/built-in.o.defconfig.*
         text    data     bss     dec     hex filename
        66358     933     100   67391   1073f net/bluetooth/built-in.o.defconfig.new
        66643     933     100   67676   1085c net/bluetooth/built-in.o.defconfig.old
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      e1447d8d
    • J
      Bluetooth: Rename function bt_err to bt_to_errno · e175072f
      Joe Perches 提交于
      Make it easier to use more normal logging styles later.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      e175072f
  10. 10 6月, 2011 1 次提交
  11. 09 6月, 2011 1 次提交
    • J
      Bluetooth: Add BT_POWER L2CAP socket option. · 14b12d0b
      Jaikumar Ganesh 提交于
      Add BT_POWER socket option used to control the power
      characteristics of the underlying ACL link. When the remote end
      has put the link in sniff mode and the host stack wants to send
      data we need need to explicitly exit sniff mode to work well with
      certain devices (For example, A2DP on Plantronics Voyager 855).
      However, this causes problems with HID devices.
      
      Hence, moving into active mode when sending data, irrespective
      of who set the sniff mode has been made as a socket option. By
      default, we will move into active mode. HID devices can set the
      L2CAP socket option to prevent this from happening.
      
      Currently, this has been implemented for L2CAP sockets. This has been
      tested with incoming and outgoing L2CAP sockets for HID and A2DP.
      
      Based on discussions on linux-bluetooth and patches submitted by
      Andrei Emeltchenko.
      Signed-off-by: NJaikumar Ganesh <jaikumar@google.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      14b12d0b
  12. 15 2月, 2011 1 次提交
    • G
      Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko · 64274518
      Gustavo F. Padovan 提交于
      Actually doesn't make sense have these modules built separately.
      The L2CAP layer is needed by almost all Bluetooth protocols and profiles.
      There isn't any real use case without having L2CAP loaded.
      SCO is only essential for Audio transfers, but it is so small that we can
      have it loaded always in bluetooth.ko without problems.
      If you really doesn't want it you can disable SCO in the kernel config.
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      64274518
  13. 08 2月, 2011 1 次提交
    • A
      Bluetooth: Use non-flushable by default L2CAP data packets · e702112f
      Andrei Emeltchenko 提交于
      Modification of Nick Pelly <npelly@google.com> patch.
      
      With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit
      makes ACL data packets non-flushable by default on compatible chipsets, and
      adds the BT_FLUSHABLE socket option to explicitly request flushable ACL
      data packets for a given L2CAP socket. This is useful for A2DP data which can
      be safely discarded if it can not be delivered within a short time (while
      other ACL data should not be discarded).
      
      Note that making ACL data flushable has no effect unless the automatic flush
      timeout for that ACL link is changed from its default of 0 (infinite).
      
      Default packet types (for compatible chipsets):
      Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
      Bluetooth HCI H4
      Bluetooth HCI ACL Packet
          .... 0000 0000 0010 = Connection Handle: 0x0002
          ..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
          00.. .... .... .... = BC Flag: Point-To-Point (0)
          Data Total Length: 8
      Bluetooth L2CAP Packet
      
      After setting BT_FLUSHABLE
      (sock.setsockopt(274 /*SOL_BLUETOOTH*/, 8 /* BT_FLUSHABLE */, 1 /* flush */))
      Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
      Bluetooth HCI H4
      Bluetooth HCI ACL Packet
          .... 0000 0000 0010 = Connection Handle: 0x0002
          ..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
          00.. .... .... .... = BC Flag: Point-To-Point (0)
          Data Total Length: 8
      Bluetooth L2CAP Packet
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      e702112f
  14. 08 12月, 2010 1 次提交
  15. 12 10月, 2010 1 次提交
    • M
      Bluetooth: Add common code for stream-oriented recvmsg() · 796c86ee
      Mat Martineau 提交于
      This commit adds a bt_sock_stream_recvmsg() function for use by any
      Bluetooth code that uses SOCK_STREAM sockets.  This code is copied
      from rfcomm_sock_recvmsg() with minimal modifications to remove
      RFCOMM-specific functionality and improve readability.
      
      L2CAP (with the SOCK_STREAM socket type) and RFCOMM have common needs
      when it comes to reading data.  Proper stream read semantics require
      that applications can read from a stream one byte at a time and not
      lose any data.  The RFCOMM code already operated on and pulled data
      from the underlying L2CAP socket, so very few changes were required to
      make the code more generic for use with non-RFCOMM data over L2CAP.
      
      Applications that need more awareness of L2CAP frame boundaries are
      still free to use SOCK_SEQPACKET sockets, and may verify that they
      connection did not fall back to basic mode by calling getsockopt().
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      796c86ee
  16. 30 9月, 2010 1 次提交
    • G
      Bluetooth: Fix deadlock in the ERTM logic · e454c844
      Gustavo F. Padovan 提交于
      The Enhanced Retransmission Mode(ERTM) is a realiable mode of operation
      of the Bluetooth L2CAP layer. Think on it like a simplified version of
      TCP.
      The problem we were facing here was a deadlock. ERTM uses a backlog
      queue to queue incomimg packets while the user is helding the lock. At
      some moment the sk_sndbuf can be exceeded and we can't alloc new skbs
      then the code sleep with the lock to wait for memory, that stalls the
      ERTM connection once we can't read the acknowledgements packets in the
      backlog queue to free memory and make the allocation of outcoming skb
      successful.
      
      This patch actually affect all users of bt_skb_send_alloc(), i.e., all
      L2CAP modes and SCO.
      
      We are safe against socket states changes or channels deletion while the
      we are sleeping wait memory. Checking for the sk->sk_err and
      sk->sk_shutdown make the code safe, since any action that can leave the
      socket or the channel in a not usable state set one of the struct
      members at least. Then we can check both of them when getting the lock
      again and return with the proper error if something unexpected happens.
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi>
      e454c844
  17. 22 7月, 2010 2 次提交
  18. 21 3月, 2010 1 次提交
  19. 07 10月, 2009 1 次提交
  20. 23 8月, 2009 3 次提交
  21. 09 6月, 2009 1 次提交
  22. 08 6月, 2009 1 次提交
  23. 27 2月, 2009 2 次提交
    • M
      Bluetooth: Add enhanced security model for Simple Pairing · 8c1b2355
      Marcel Holtmann 提交于
      The current security model is based around the flags AUTH, ENCRYPT and
      SECURE. Starting with support for the Bluetooth 2.1 specification this is
      no longer sufficient. The different security levels are now defined as
      SDP, LOW, MEDIUM and SECURE.
      
      Previously it was possible to set each security independently, but this
      actually doesn't make a lot of sense. For Bluetooth the encryption depends
      on a previous successful authentication. Also you can only update your
      existing link key if you successfully created at least one before. And of
      course the update of link keys without having proper encryption in place
      is a security issue.
      
      The new security levels from the Bluetooth 2.1 specification are now
      used internally. All old settings are mapped to the new values and this
      way it ensures that old applications still work. The only limitation
      is that it is no longer possible to set authentication without also
      enabling encryption. No application should have done this anyway since
      this is actually a security issue. Without encryption the integrity of
      the authentication can't be guaranteed.
      
      As default for a new L2CAP or RFCOMM connection, the LOW security level
      is used. The only exception here are the service discovery sessions on
      PSM 1 where SDP level is used. To have similar security strength as with
      a Bluetooth 2.0 and before combination key, the MEDIUM level should be
      used. This is according to the Bluetooth specification. The MEDIUM level
      will not require any kind of man-in-the-middle (MITM) protection. Only
      the HIGH security level will require this.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8c1b2355
    • M
      Bluetooth: Add global deferred socket parameter · c4f912e1
      Marcel Holtmann 提交于
      The L2CAP and RFCOMM applications require support for authorization
      and the ability of rejecting incoming connection requests. The socket
      interface is not really able to support this.
      
      This patch does the ground work for a socket option to defer connection
      setup. Setting this option allows calling of accept() and then the
      first read() will trigger the final connection setup. Calling close()
      would reject the connection.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c4f912e1
  24. 30 11月, 2008 1 次提交
  25. 17 10月, 2008 1 次提交
  26. 15 7月, 2008 1 次提交
  27. 06 3月, 2008 1 次提交
  28. 04 7月, 2006 1 次提交
  29. 09 11月, 2005 1 次提交
  30. 29 10月, 2005 1 次提交
  31. 09 10月, 2005 1 次提交
  32. 30 8月, 2005 2 次提交
  33. 06 8月, 2005 1 次提交
  34. 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