1. 21 10月, 2015 3 次提交
    • J
      Bluetooth: Fix missing hdev locking for LE scan cleanup · 8ce783dc
      Johan Hedberg 提交于
      The hci_conn objects don't have a dedicated lock themselves but rely
      on the caller to hold the hci_dev lock for most types of access. The
      hci_conn_timeout() function has so far sent certain HCI commands based
      on the hci_conn state which has been possible without holding the
      hci_dev lock.
      
      The recent changes to do LE scanning before connect attempts added
      even more operations to hci_conn and hci_dev from hci_conn_timeout,
      thereby exposing potential race conditions with the hci_dev and
      hci_conn states.
      
      As an example of such a race, here there's a timeout but an
      l2cap_sock_connect() call manages to race with the cleanup routine:
      
      [Oct21 08:14] l2cap_chan_timeout: chan ee4b12c0 state BT_CONNECT
      [  +0.000004] l2cap_chan_close: chan ee4b12c0 state BT_CONNECT
      [  +0.000002] l2cap_chan_del: chan ee4b12c0, conn f3141580, err 111, state BT_CONNECT
      [  +0.000002] l2cap_sock_teardown_cb: chan ee4b12c0 state BT_CONNECT
      [  +0.000005] l2cap_chan_put: chan ee4b12c0 orig refcnt 4
      [  +0.000010] hci_conn_drop: hcon f53d56e0 orig refcnt 1
      [  +0.000013] l2cap_chan_put: chan ee4b12c0 orig refcnt 3
      [  +0.000063] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT
      [  +0.000049] hci_conn_params_del: addr ee:0d:30:09:53:1f (type 1)
      [  +0.000002] hci_chan_list_flush: hcon f53d56e0
      [  +0.000001] hci_chan_del: hci0 hcon f53d56e0 chan f4e7ccc0
      [  +0.004528] l2cap_sock_create: sock e708fc00
      [  +0.000023] l2cap_chan_create: chan ee4b1770
      [  +0.000001] l2cap_chan_hold: chan ee4b1770 orig refcnt 1
      [  +0.000002] l2cap_sock_init: sk ee4b3390
      [  +0.000029] l2cap_sock_bind: sk ee4b3390
      [  +0.000010] l2cap_sock_setsockopt: sk ee4b3390
      [  +0.000037] l2cap_sock_connect: sk ee4b3390
      [  +0.000002] l2cap_chan_connect: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f (type 2) psm 0x00
      [  +0.000002] hci_get_route: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f
      [  +0.000001] hci_dev_hold: hci0 orig refcnt 8
      [  +0.000003] hci_conn_hold: hcon f53d56e0 orig refcnt 0
      
      Above the l2cap_chan_connect() shouldn't have been able to reach the
      hci_conn f53d56e0 anymore but since hci_conn_timeout didn't do proper
      locking that's not the case. The end result is a reference to hci_conn
      that's not in the conn_hash list, resulting in list corruption when
      trying to remove it later:
      
      [Oct21 08:15] l2cap_chan_timeout: chan ee4b1770 state BT_CONNECT
      [  +0.000004] l2cap_chan_close: chan ee4b1770 state BT_CONNECT
      [  +0.000003] l2cap_chan_del: chan ee4b1770, conn f3141580, err 111, state BT_CONNECT
      [  +0.000001] l2cap_sock_teardown_cb: chan ee4b1770 state BT_CONNECT
      [  +0.000005] l2cap_chan_put: chan ee4b1770 orig refcnt 4
      [  +0.000002] hci_conn_drop: hcon f53d56e0 orig refcnt 1
      [  +0.000015] l2cap_chan_put: chan ee4b1770 orig refcnt 3
      [  +0.000038] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT
      [  +0.000003] hci_chan_list_flush: hcon f53d56e0
      [  +0.000002] hci_conn_hash_del: hci0 hcon f53d56e0
      [  +0.000001] ------------[ cut here ]------------
      [  +0.000461] WARNING: CPU: 0 PID: 1782 at lib/list_debug.c:56 __list_del_entry+0x3f/0x71()
      [  +0.000839] list_del corruption, f53d56e0->prev is LIST_POISON2 (00000200)
      
      The necessary fix is unfortunately more complicated than just adding
      hci_dev_lock/unlock calls to the hci_conn_timeout() call path.
      Particularly, the hci_conn_del() API, which expects the hci_dev lock to
      be held, performs a cancel_delayed_work_sync(&hcon->disc_work) which
      would lead to a deadlock if the hci_conn_timeout() call path tries to
      acquire the same lock.
      
      This patch solves the problem by deferring the cleanup work to a
      separate work callback. To protect against the hci_dev or hci_conn
      going away meanwhile temporary references are taken with the help of
      hci_dev_hold() and hci_conn_get().
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org # 4.3
      8ce783dc
    • M
      Bluetooth: Introduce driver specific post init callback · 98a63aaf
      Marcel Holtmann 提交于
      Some drivers might have to restore certain settings after the init
      procedure has been completed. This driver callback allows them to hook
      into that stage. This callback is run just before the controller is
      declared as powered up.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      98a63aaf
    • J
      Bluetooth: Don't use remote address type to decide IRK persistency · cad20c27
      Johan Hedberg 提交于
      There are LE devices on the market that start off by announcing their
      public address and then once paired switch to using private address.
      To be interoperable with such devices we should simply trust the fact
      that we're receiving an IRK from them to indicate that they may use
      private addresses in the future. Instead, simply tie the persistency
      to the bonding/no-bonding information the same way as for LTKs and
      CSRKs.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cad20c27
  2. 08 10月, 2015 2 次提交
  3. 29 9月, 2015 1 次提交
  4. 17 9月, 2015 1 次提交
  5. 11 8月, 2015 3 次提交
    • J
      Bluetooth: add hci_connect_le_scan · f75113a2
      Jakub Pawlowski 提交于
      Currently, when trying to connect to already paired device that just
      rotated its RPA MAC address, old address would be used and connection
      would fail. In order to fix that, kernel must scan and receive
      advertisement with fresh RPA before connecting.
      
      This patch adds hci_connect_le_scan with dependencies, new method that
      will be used to connect to remote LE devices. Instead of just sending
      connect request, it adds a device to whitelist. Later patches will make
      use of this whitelist to send conenct request when advertisement is
      received, and properly handle timeouts.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f75113a2
    • J
      Bluetooth: add hci_lookup_le_connect · e7d9ab73
      Jakub Pawlowski 提交于
      This patch adds hci_lookup_le_connect method, that will be used to check
      wether outgoing le connection attempt is in progress.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e7d9ab73
    • J
      Bluetooth: preparation for new connect procedure · 158e9218
      Jakub Pawlowski 提交于
      Currently, when trying to connect to already paired device that just
      rotated its RPA MAC address, old address would be used and connection
      would fail. In order to fix that, kernel must scan and receive
      advertisement with fresh RPA before connecting.
      
      This patch adds some fields to hci_conn_params, in preparation to new
      connect procedure.
      
      explicit_connect will be used to override any current auto_connect action,
      and connect to device when ad is received.
      
      HCI_AUTO_CONN_EXPLICIT was added to auto_connect enum. When this value
      will be used, explicit connect is the only action, and params can be
      removed after successful connection.
      
      HCI_CONN_SCANNING is added to hci_conn flags. When it's set, connect is
      scan phase. It gets cleared when advertisement is received, and
      HCI_OP_LE_CREATE_CONN is sent.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      158e9218
  6. 23 7月, 2015 1 次提交
  7. 19 6月, 2015 5 次提交
  8. 09 6月, 2015 3 次提交
  9. 08 4月, 2015 2 次提交
  10. 02 4月, 2015 4 次提交
  11. 24 3月, 2015 2 次提交
  12. 18 3月, 2015 2 次提交
  13. 16 3月, 2015 1 次提交
  14. 15 3月, 2015 4 次提交
  15. 14 3月, 2015 2 次提交
  16. 13 3月, 2015 4 次提交