1. 13 11月, 2014 3 次提交
    • J
      Bluetooth: Fix L2CAP nesting level initialization location · ff714119
      Johan Hedberg 提交于
      There's no reason why all users of L2CAP would need to worry about
      initializing chan->nesting to L2CAP_NESTING_NORMAL (which is important
      since 0 is the same as NESTING_SMP). This patch moves the initialization
      to the common place that's used to create all new channels, i.e. the
      l2cap_chan_create() function.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      ff714119
    • J
      Bluetooth: Fix L2CAP socket lock nesting level · 3b2ab39e
      Johan Hedberg 提交于
      The teardown callback for L2CAP channels is problematic in that it is
      explicitly called for all types of channels from l2cap_chan_del(),
      meaning it's not possible to hard-code a nesting level when taking the
      socket lock. The simplest way to have a correct nesting level for the
      socket locking is to use the same value as for the chan. This also means
      that the other places trying to lock parent sockets need to be update to
      use the chan value (since L2CAP_NESTING_PARENT is defined as 2 whereas
      SINGLE_DEPTH_NESTING has the value 1).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      3b2ab39e
    • J
      Bluetooth: Use proper nesting annotation for l2cap_chan lock · abe84903
      Johan Hedberg 提交于
      By default lockdep considers all L2CAP channels equal. This would mean
      that we get warnings if a channel is locked when another one's lock is
      tried to be acquired in the same thread. This kind of inter-channel
      locking dependencies exist in the form of parent-child channels as well
      as any channel wishing to elevate the security by requesting procedures
      on the SMP channel.
      
      To eliminate the chance for these lockdep warnings we introduce a
      nesting level for each channel and use that when acquiring the channel
      lock. For now there exists the earlier mentioned three identified
      categories: SMP, "normal" channels and parent channels (i.e. those in
      BT_LISTEN state). The nesting level is defined as atomic_t since we need
      access to it before the lock is actually acquired.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      abe84903
  2. 12 11月, 2014 2 次提交
    • J
      Bluetooth: Remove unnecessary hci_dev_lock/unlock in smp.c · a930430b
      Johan Hedberg 提交于
      The mgmt_user_passkey_request and related functions do not do anything
      else except read access to hdev->id. This member never changes after the
      hdev creation so there is no need to acquire a lock to read it.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a930430b
    • J
      Bluetooth: Fix l2cap_sock_teardown_cb lockdep warning · f0356704
      Johan Hedberg 提交于
      Any code calling bt_accept_dequeue() to get a new child socket from a
      server socket should use lock_sock_nested to avoid lockdep warnings due
      to the parent and child sockets being locked at the same time. The
      l2cap_sock_accept() function is already doing this correctly but a
      second place calling bt_accept_dequeue() is the code path from
      l2cap_sock_teardown_cb() that calls l2cap_sock_cleanup_listen().
      
      This patch fixes the proper nested locking annotation and thereby avoids
      the following style of lockdep warning.
      
      [  +0.000224] [ INFO: possible recursive locking detected ]
      [  +0.000222] 3.17.0+ #1153 Not tainted
      [  +0.000130] ---------------------------------------------
      [  +0.000227] l2cap-tester/562 is trying to acquire lock:
      [  +0.000210]  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<c1393f47>] bt_accept_dequeue+0x68/0x11b
      [  +0.000467]
      but task is already holding lock:
      [  +0.000186]  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<c13b949a>] lock_sock+0xa/0xc
      [  +0.000421]
      other info that might help us debug this:
      [  +0.000199]  Possible unsafe locking scenario:
      
      [  +0.000117]        CPU0
      [  +0.000000]        ----
      [  +0.000000]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
      [  +0.000000]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
      [  +0.000000]
       *** DEADLOCK ***
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f0356704
  3. 11 11月, 2014 3 次提交
    • J
      Bluetooth: 6lowpan: Remove unnecessary RCU callback · 4e790226
      Johan Hedberg 提交于
      When kfree() is all that's needed to free an object protected by RCU
      there's a kfree_rcu() convenience function that can be used. This patch
      updates the 6lowpan code to use this, thereby eliminating the need for
      the separate peer_free() function.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4e790226
    • J
      Bluetooth: Fix mgmt connected notification · 60cb49d2
      Johan Hedberg 提交于
      This patch fixes a regression that was introduced by commit
      cb77c3ec. In addition to BT_CONFIG,
      BT_CONNECTED is also a state in which we may get a remote name and need
      to indicate over mgmt the connection status. This scenario is
      particularly likely to happen for incoming connections that do not need
      authentication since there the hci_conn state will reach BT_CONNECTED
      before the remote name is received.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      60cb49d2
    • J
      Bluetooth: Fix sparse warning in amp.c · 252670c4
      Johan Hedberg 提交于
      This fixes the following sparse warning:
      
      net/bluetooth/amp.c:152:53: warning: Variable length array is used.
      
      The warning itself is probably harmless since this kind of usage of
      shash_desc is present also in other places in the kernel (there's even a
      convenience macro SHASH_DESC_ON_STACK available for defining such stack
      variables). However, dynamically allocated versions are also used in
      several places of the kernel (e.g. kernel/kexec.c and lib/digsig.c)
      which have the benefit of not exhibiting the sparse warning.
      
      Since there are no more sparse warnings in the Bluetooth subsystem after
      fixing this one it is now easier to spot whenever new ones might get
      introduced by future patches.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      252670c4
  4. 09 11月, 2014 1 次提交
  5. 07 11月, 2014 4 次提交
    • J
      Bluetooth: Send mgmt_connected only if state is BT_CONFIG · cb77c3ec
      Jaganath Kanakkassery 提交于
      If a remote name request is initiated while acl connection is going on,
      and if it fails then mgmt_connected will be sent. Evetually after acl
      connection, authentication will not be initiated and userspace will
      never get pairing reply.
      
      < HCI Command: Create Connection (0x01|0x0005) plen 13
          bdaddr AA:BB:CC:DD:EE:FF ptype 0xcc18 rswitch 0x01 clkoffset 0x2306 (valid)
          Packet type: DM1 DM3 DM5 DH1 DH3 DH5
      > HCI Event: Command Status (0x0f) plen 4
          Create Connection (0x01|0x0005) status 0x00 ncmd 1
      > HCI Event: Inquiry Complete (0x01) plen 1
          status 0x00
      < HCI Command: Remote Name Request (0x01|0x0019) plen 10
          bdaddr AA:BB:CC:DD:EE:FF mode 1 clkoffset 0x2306
      > HCI Event: Command Status (0x0f) plen 4
          Remote Name Request (0x01|0x0019) status 0x0c ncmd 1
          Error: Command Disallowed
      > HCI Event: Connect Complete (0x03) plen 11
          status 0x00 handle 50 bdaddr 00:0D:FD:47:53:B2 type ACL encrypt 0x00
      < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
          handle 50
      > HCI Event: Command Status (0x0f) plen 4
          Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
      > HCI Event: Max Slots Change (0x1b) plen 3
          handle 50 slots 5
      > HCI Event: Read Remote Supported Features (0x0b) plen 11
          status 0x00 handle 50
          Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83
      < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
          handle 50 page 1
      > HCI Event: Command Status (0x0f) plen 4
          Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
      > HCI Event: Read Remote Extended Features (0x23) plen 13
          status 0x00 handle 50 page 1 max 1
          Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
      
      This patch sends mgmt_connected in remote name command status only if
      conn->state is BT_CONFIG
      Signed-off-by: NJaganath Kanakkassery <jaganath.k@samsung.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      cb77c3ec
    • M
      6lowpan: move skb_free from error paths in decompression · 56b2c3ee
      Martin Townsend 提交于
      Currently we ensure that the skb is freed on every error path in IPHC
      decompression which makes it easy to introduce skb leaks.  By centralising
      the skb_free into the receive function it makes future decompression routines
      easier to maintain.  It does come at the expense of ensuring that the skb
      passed into the decompression routine must not be copied.
      Signed-off-by: NMartin Townsend <mtownsend1973@gmail.com>
      Acked-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Acked-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      56b2c3ee
    • K
      Bluetooth: Sort switch cases by opcode's numeric value · 9645c76c
      Kuba Pawlak 提交于
      Opcodes in switch/case in hci_cmd_status_evt are not sorted
      by value. This patch restores proper ordering.
      Signed-off-by: NKuba Pawlak <kubax.t.pawlak@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9645c76c
    • K
      Bluetooth: Clear role switch pending flag · 50fc85f1
      Kuba Pawlak 提交于
      If role switch was rejected by the controller and HCI Event: Command Status
      returned with status "Command Disallowed" (0x0C) the flag
      HCI_CONN_RSWITCH_PEND remains set. No further role switches are
      possible as this flag prevents us from sending any new HCI Switch Role
      requests and the only way to clear it is to receive a valid
      HCI Event Switch Role.
      
      This patch clears the flag if command was rejected.
      
      2013-01-01 00:03:44.209913 < HCI Command: Switch Role (0x02|0x000b) plen 7
          bdaddr BC:C6:DB:C4:6F:79 role 0x00
          Role: Master
      2013-01-01 00:03:44.210867 > HCI Event: Command Status (0x0f) plen 4
          Switch Role (0x02|0x000b) status 0x0c ncmd 1
          Error: Command Disallowed
      Signed-off-by: NKuba Pawlak <kubax.t.pawlak@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      50fc85f1
  6. 04 11月, 2014 1 次提交
  7. 03 11月, 2014 2 次提交
  8. 02 11月, 2014 5 次提交
  9. 31 10月, 2014 2 次提交
  10. 29 10月, 2014 6 次提交
  11. 28 10月, 2014 1 次提交
  12. 27 10月, 2014 4 次提交
  13. 26 10月, 2014 4 次提交
  14. 25 10月, 2014 2 次提交