Commit a9999348 authored by Johan Hedberg's avatar Johan Hedberg Committed by Marcel Holtmann

Bluetooth: Remove unnecessary hci_dev_unlock for smp_user_confirm_reply

Now that the SMP context has it's own crypto handle it doesn't need to
lock the hci_dev anymore for most operations. This means that it is safe
to call smp_user_confirm_reply with the lock already held.
Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
parent ec70f36f
...@@ -3052,14 +3052,7 @@ static int user_pairing_resp(struct sock *sk, struct hci_dev *hdev, ...@@ -3052,14 +3052,7 @@ static int user_pairing_resp(struct sock *sk, struct hci_dev *hdev,
} }
if (addr->type == BDADDR_LE_PUBLIC || addr->type == BDADDR_LE_RANDOM) { if (addr->type == BDADDR_LE_PUBLIC || addr->type == BDADDR_LE_RANDOM) {
/* Continue with pairing via SMP. The hdev lock must be
* released as SMP may try to recquire it for crypto
* purposes.
*/
hci_dev_unlock(hdev);
err = smp_user_confirm_reply(conn, mgmt_op, passkey); err = smp_user_confirm_reply(conn, mgmt_op, passkey);
hci_dev_lock(hdev);
if (!err) if (!err)
err = cmd_complete(sk, hdev->id, mgmt_op, err = cmd_complete(sk, hdev->id, mgmt_op,
MGMT_STATUS_SUCCESS, addr, MGMT_STATUS_SUCCESS, addr,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment