1. 19 2月, 2015 3 次提交
  2. 15 2月, 2015 1 次提交
  3. 02 2月, 2015 2 次提交
  4. 31 1月, 2015 1 次提交
  5. 29 1月, 2015 1 次提交
  6. 24 1月, 2015 1 次提交
  7. 16 1月, 2015 1 次提交
  8. 13 1月, 2015 1 次提交
  9. 03 1月, 2015 1 次提交
  10. 21 12月, 2014 1 次提交
  11. 20 12月, 2014 3 次提交
  12. 19 12月, 2014 2 次提交
  13. 05 12月, 2014 3 次提交
  14. 03 12月, 2014 7 次提交
  15. 19 11月, 2014 1 次提交
  16. 18 11月, 2014 1 次提交
  17. 15 11月, 2014 2 次提交
  18. 03 11月, 2014 1 次提交
  19. 02 11月, 2014 1 次提交
  20. 25 10月, 2014 3 次提交
  21. 17 9月, 2014 1 次提交
  22. 09 9月, 2014 2 次提交
    • J
      Bluetooth: Fix mgmt pairing failure when authentication fails · e1e930f5
      Johan Hedberg 提交于
      Whether through HCI with BR/EDR or SMP with LE when authentication fails
      we should also notify any pending Pair Device mgmt command. This patch
      updates the mgmt_auth_failed function to take the actual hci_conn object
      and makes sure that any pending pairing command is notified and cleaned
      up appropriately.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e1e930f5
    • J
      Bluetooth: Fix locking of the SMP context · fc75cc86
      Johan Hedberg 提交于
      Before the move the l2cap_chan the SMP context (smp_chan) didn't have
      any kind of proper locking. The best there existed was the
      HCI_CONN_LE_SMP_PEND flag which was used to enable mutual exclusion for
      potential multiple creators of the SMP context.
      
      Now that SMP has been converted to use the l2cap_chan infrastructure and
      since the SMP context is directly mapped to a corresponding l2cap_chan
      we get the SMP context locking essentially for free through the
      l2cap_chan lock. For all callbacks that l2cap_core.c makes for each
      channel implementation (smp.c in the case of SMP) the l2cap_chan lock is
      held through l2cap_chan_lock(chan).
      
      Since the calls from l2cap_core.c to smp.c are covered the only missing
      piece to have the locking implemented properly is to ensure that the
      lock is held for any other call path that may access the SMP context.
      This means user responses through mgmt.c, requests to elevate the
      security of a connection through hci_conn.c, as well as any deferred
      work through workqueues.
      
      This patch adds the necessary locking to all these other code paths that
      try to access the SMP context. Since mutual exclusion for the l2cap_chan
      access is now covered from all directions the patch also removes
      unnecessary HCI_CONN_LE_SMP_PEND flag (once we've acquired the chan lock
      we can simply check whether chan->smp is set to know if there's an SMP
      context).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      fc75cc86