summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSonny Sasaka <sonnysasaka@chromium.org>2020-05-06 12:55:03 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-10-01 13:12:43 +0200
commitd16f05223ad8ad19f2a7910035f3893a47893a38 (patch)
tree9d3880529ac0b5a3da7dd0f9229cd5224f226f51
parente9d79b176ffec288f11c059478050d1f9f52c11f (diff)
downloadlinux-stable-d16f05223ad8ad19f2a7910035f3893a47893a38.tar.gz
linux-stable-d16f05223ad8ad19f2a7910035f3893a47893a38.tar.bz2
linux-stable-d16f05223ad8ad19f2a7910035f3893a47893a38.zip
Bluetooth: Handle Inquiry Cancel error after Inquiry Complete
[ Upstream commit adf1d6926444029396861413aba8a0f2a805742a ] After sending Inquiry Cancel command to the controller, it is possible that Inquiry Complete event comes before Inquiry Cancel command complete event. In this case the Inquiry Cancel command will have status of Command Disallowed since there is no Inquiry session to be cancelled. This case should not be treated as error, otherwise we can reach an inconsistent state. Example of a btmon trace when this happened: < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0 > HCI Event: Inquiry Complete (0x01) plen 1 Status: Success (0x00) > HCI Event: Command Complete (0x0e) plen 4 Inquiry Cancel (0x01|0x0002) ncmd 1 Status: Command Disallowed (0x0c) Signed-off-by: Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-rw-r--r--net/bluetooth/hci_event.c19
1 files changed, 17 insertions, 2 deletions
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 1d2f43904366..587b674bbcd6 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -41,12 +41,27 @@
/* Handle HCI Event packets */
-static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff *skb)
+static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff *skb,
+ u8 *new_status)
{
__u8 status = *((__u8 *) skb->data);
BT_DBG("%s status 0x%2.2x", hdev->name, status);
+ /* It is possible that we receive Inquiry Complete event right
+ * before we receive Inquiry Cancel Command Complete event, in
+ * which case the latter event should have status of Command
+ * Disallowed (0x0c). This should not be treated as error, since
+ * we actually achieve what Inquiry Cancel wants to achieve,
+ * which is to end the last Inquiry session.
+ */
+ if (status == 0x0c && !test_bit(HCI_INQUIRY, &hdev->flags)) {
+ bt_dev_warn(hdev, "Ignoring error of Inquiry Cancel command");
+ status = 0x00;
+ }
+
+ *new_status = status;
+
if (status)
return;
@@ -2772,7 +2787,7 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb,
switch (*opcode) {
case HCI_OP_INQUIRY_CANCEL:
- hci_cc_inquiry_cancel(hdev, skb);
+ hci_cc_inquiry_cancel(hdev, skb, status);
break;
case HCI_OP_PERIODIC_INQ: