[PATCH 1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[PATCH 1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[Hans de Goede]

From: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com>

A synchronous HCI command that never receives a response leaves
HCI_CMD_PENDING set: hci_req_cmd_complete() is the only place that clears
it, and it only runs when a response matching the last command sent
arrives.

hci_send_cmd_sync() populates hdev->req_skb only when the flag transitions
from clear to set, while hci_dev_open_sync() and hci_dev_close_sync() drop
req_skb without clearing the flag. After a timeout followed by either, the
two disagree: the flag claims a request is outstanding while req_skb is
NULL. Subsequent synchronous commands are then sent with no req_skb, so
hci_event_packet() has nothing to match an arriving event against, and the
caller times out even though the controller answered.

Commands answered by Command Complete recover on their own, since
hci_req_cmd_complete() clears the flag as a side effect. Drivers using
__hci_cmd_sync_ev() with a custom event do not, because a vendor event
never reaches that path. On a WCN3988 (hci_qca over UART) this makes a
controller firmware hang unrecoverable: the driver injects a hardware
error and re-runs qca_setup(), qca_read_soc_version() waits for
HCI_EV_VENDOR, the reply arrives within 4 ms and is discarded, and every
retry fails the same way. The adapter is left down until the driver is
unbound and rebound, or power is removed.

Clear the flag wherever the last request is dropped, restoring the
invariant that req_skb is non-NULL exactly when HCI_CMD_PENDING is set.
Verified on hardware by forcing a command timeout: without this change
setup fails on every attempt, with it setup succeeds on the first.

Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback")
Cc: stable@vger.kernel.org
Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
 net/bluetooth/hci_sync.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 532534bc601c..33ee71c56480 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -5302,6 +5302,7 @@ int hci_dev_open_sync(struct hci_dev *hdev)
 		if (hdev->req_skb) {
 			kfree_skb(hdev->req_skb);
 			hdev->req_skb = NULL;
+			hci_dev_clear_flag(hdev, HCI_CMD_PENDING);
 		}
 
 		clear_bit(HCI_RUNNING, &hdev->flags);
@@ -5486,6 +5487,7 @@ int hci_dev_close_sync(struct hci_dev *hdev)
 	if (hdev->req_skb) {
 		kfree_skb(hdev->req_skb);
 		hdev->req_skb = NULL;
+		hci_dev_clear_flag(hdev, HCI_CMD_PENDING);
 	}
 
 	clear_bit(HCI_RUNNING, &hdev->flags);
-- 
2.55.0

[PATCH 2/2] Bluetooth: hci_sync: Factor common cleanup code into a helper

[Hans de Goede]

The hci_dev_init_sync() failure path in hci_dev_open_sync() and the cleanup
code in hci_dev_close_sync() have a bunch of common code.

Factor this duplicate code out into a hci_dev_drop_last_cmd_req_and_close()
helper function.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
 net/bluetooth/hci_sync.c | 64 +++++++++++++++++-----------------------
 1 file changed, 27 insertions(+), 37 deletions(-)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 33ee71c56480..9e62f1d392ce 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -5207,6 +5207,30 @@ static int hci_dev_init_sync(struct hci_dev *hdev)
 	return ret;
 }
 
+static void hci_dev_drop_last_cmd_req_and_close(struct hci_dev *hdev)
+{
+	/* Drop last sent command */
+	if (hdev->sent_cmd) {
+		cancel_delayed_work_sync(&hdev->cmd_timer);
+		kfree_skb(hdev->sent_cmd);
+		hdev->sent_cmd = NULL;
+	}
+
+	/* Drop last request */
+	if (hdev->req_skb) {
+		kfree_skb(hdev->req_skb);
+		hdev->req_skb = NULL;
+		hci_dev_clear_flag(hdev, HCI_CMD_PENDING);
+	}
+
+	clear_bit(HCI_RUNNING, &hdev->flags);
+	hci_sock_dev_event(hdev, HCI_DEV_CLOSE);
+
+	/* After this point our queues are empty and no tasks are scheduled. */
+	hdev->close(hdev);
+	hdev->flags &= BIT(HCI_RAW);
+}
+
 int hci_dev_open_sync(struct hci_dev *hdev)
 {
 	int ret;
@@ -5293,23 +5317,7 @@ int hci_dev_open_sync(struct hci_dev *hdev)
 		if (hdev->flush)
 			hdev->flush(hdev);
 
-		if (hdev->sent_cmd) {
-			cancel_delayed_work_sync(&hdev->cmd_timer);
-			kfree_skb(hdev->sent_cmd);
-			hdev->sent_cmd = NULL;
-		}
-
-		if (hdev->req_skb) {
-			kfree_skb(hdev->req_skb);
-			hdev->req_skb = NULL;
-			hci_dev_clear_flag(hdev, HCI_CMD_PENDING);
-		}
-
-		clear_bit(HCI_RUNNING, &hdev->flags);
-		hci_sock_dev_event(hdev, HCI_DEV_CLOSE);
-
-		hdev->close(hdev);
-		hdev->flags &= BIT(HCI_RAW);
+		hci_dev_drop_last_cmd_req_and_close(hdev);
 	}
 
 done:
@@ -5476,28 +5484,10 @@ int hci_dev_close_sync(struct hci_dev *hdev)
 	skb_queue_purge(&hdev->cmd_q);
 	skb_queue_purge(&hdev->raw_q);
 
-	/* Drop last sent command */
-	if (hdev->sent_cmd) {
-		cancel_delayed_work_sync(&hdev->cmd_timer);
-		kfree_skb(hdev->sent_cmd);
-		hdev->sent_cmd = NULL;
-	}
-
-	/* Drop last request */
-	if (hdev->req_skb) {
-		kfree_skb(hdev->req_skb);
-		hdev->req_skb = NULL;
-		hci_dev_clear_flag(hdev, HCI_CMD_PENDING);
-	}
-
-	clear_bit(HCI_RUNNING, &hdev->flags);
-	hci_sock_dev_event(hdev, HCI_DEV_CLOSE);
-
-	/* After this point our queues are empty and no tasks are scheduled. */
-	hdev->close(hdev);
+	/* Drop last sent command, last request and close */
+	hci_dev_drop_last_cmd_req_and_close(hdev);
 
 	/* Clear flags */
-	hdev->flags &= BIT(HCI_RAW);
 	hci_dev_clear_volatile_flags(hdev);
 	hci_dev_clear_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE);
 
-- 
2.55.0

RE: [1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1143947

---Test result---

Test Summary:
CheckPatch                    PASS      1.86 seconds
VerifyFixes                   PASS      0.13 seconds
VerifySignedoff               PASS      0.13 seconds
GitLint                       PASS      0.67 seconds
SubjectPrefix                 PASS      0.26 seconds
BuildKernel                   PASS      28.31 seconds
CheckAllWarning               PASS      30.35 seconds
CheckSparse                   PASS      28.39 seconds
BuildKernel32                 PASS      29.13 seconds
CheckKernelLLVM               SKIP      0.00 seconds
TestRunnerSetup               PASS      503.14 seconds
TestRunner_l2cap-tester       PASS      64.96 seconds
TestRunner_iso-tester         PASS      81.82 seconds
TestRunner_bnep-tester        PASS      19.39 seconds
TestRunner_mgmt-tester        FAIL      226.68 seconds
TestRunner_rfcomm-tester      PASS      26.62 seconds
TestRunner_sco-tester         PASS      32.84 seconds
TestRunner_ioctl-tester       PASS      27.17 seconds
TestRunner_mesh-tester        FAIL      26.97 seconds
TestRunner_smp-tester         PASS      24.42 seconds
TestRunner_userchan-tester    PASS      20.61 seconds
TestRunner_6lowpan-tester     PASS      24.04 seconds
IncrementalBuild              PASS      29.81 seconds

Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 501, Passed: 496 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.252 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.102 seconds
Mesh - Send cancel - 2                               Timed out    1.984 seconds


https://github.com/bluez/bluetooth-next/pull/569

---
Regards,
Linux Bluetooth

Re: [1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[johannes.goede]

Hi,

On 11-Aug-26 11:22, bluez.test.bot@gmail.com wrote:
> This is automated email and please do not reply to this email!
> 
> Dear submitter,
> 
> Thank you for submitting the patches to the linux bluetooth mailing list.
> This is a CI test results with your patch series:
> PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1143947
> 
> ---Test result---
> 
> Test Summary:
> CheckPatch                    PASS      1.86 seconds
> VerifyFixes                   PASS      0.13 seconds
> VerifySignedoff               PASS      0.13 seconds
> GitLint                       PASS      0.67 seconds
> SubjectPrefix                 PASS      0.26 seconds
> BuildKernel                   PASS      28.31 seconds
> CheckAllWarning               PASS      30.35 seconds
> CheckSparse                   PASS      28.39 seconds
> BuildKernel32                 PASS      29.13 seconds
> CheckKernelLLVM               SKIP      0.00 seconds
> TestRunnerSetup               PASS      503.14 seconds
> TestRunner_l2cap-tester       PASS      64.96 seconds
> TestRunner_iso-tester         PASS      81.82 seconds
> TestRunner_bnep-tester        PASS      19.39 seconds
> TestRunner_mgmt-tester        FAIL      226.68 seconds
> TestRunner_rfcomm-tester      PASS      26.62 seconds
> TestRunner_sco-tester         PASS      32.84 seconds
> TestRunner_ioctl-tester       PASS      27.17 seconds
> TestRunner_mesh-tester        FAIL      26.97 seconds
> TestRunner_smp-tester         PASS      24.42 seconds
> TestRunner_userchan-tester    PASS      20.61 seconds
> TestRunner_6lowpan-tester     PASS      24.04 seconds
> IncrementalBuild              PASS      29.81 seconds
> 
> Details
> ##############################
> Test: CheckKernelLLVM - SKIP
> Desc: Build kernel with LLVM + context analysis
> Output:
> Clang not found
> ##############################
> Test: TestRunner_mgmt-tester - FAIL
> Desc: Run mgmt-tester with test-runner
> Output:
> Total: 501, Passed: 496 (99.0%), Failed: 1, Not Run: 4
> 
> Failed Test Cases
> Read Exp Feature - Success                           Failed       0.252 seconds
> ##############################
> Test: TestRunner_mesh-tester - FAIL
> Desc: Run mesh-tester with test-runner
> Output:
> Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
> 
> Failed Test Cases
> Mesh - Send cancel - 1                               Timed out    2.102 seconds
> Mesh - Send cancel - 2                               Timed out    1.984 seconds

I'm seeing the exact same failures in other CI runs from recent
patches, e.g. :

https://lore.kernel.org/linux-bluetooth/20260808062541.3705446-1-zhangchen200426@163.com/T/#t

So I'm assuming that these are pre-existing CI issues and
not caused by this patch.

Regards,

Hans

Re: [1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[Luiz Augusto von Dentz]

Hi,

On Tue, Aug 11, 2026 at 7:05 AM <johannes.goede@oss.qualcomm.com> wrote:
>
> Hi,
>
> On 11-Aug-26 11:22, bluez.test.bot@gmail.com wrote:
> > This is automated email and please do not reply to this email!
> >
> > Dear submitter,
> >
> > Thank you for submitting the patches to the linux bluetooth mailing list.
> > This is a CI test results with your patch series:
> > PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1143947
> >
> > ---Test result---
> >
> > Test Summary:
> > CheckPatch                    PASS      1.86 seconds
> > VerifyFixes                   PASS      0.13 seconds
> > VerifySignedoff               PASS      0.13 seconds
> > GitLint                       PASS      0.67 seconds
> > SubjectPrefix                 PASS      0.26 seconds
> > BuildKernel                   PASS      28.31 seconds
> > CheckAllWarning               PASS      30.35 seconds
> > CheckSparse                   PASS      28.39 seconds
> > BuildKernel32                 PASS      29.13 seconds
> > CheckKernelLLVM               SKIP      0.00 seconds
> > TestRunnerSetup               PASS      503.14 seconds
> > TestRunner_l2cap-tester       PASS      64.96 seconds
> > TestRunner_iso-tester         PASS      81.82 seconds
> > TestRunner_bnep-tester        PASS      19.39 seconds
> > TestRunner_mgmt-tester        FAIL      226.68 seconds
> > TestRunner_rfcomm-tester      PASS      26.62 seconds
> > TestRunner_sco-tester         PASS      32.84 seconds
> > TestRunner_ioctl-tester       PASS      27.17 seconds
> > TestRunner_mesh-tester        FAIL      26.97 seconds
> > TestRunner_smp-tester         PASS      24.42 seconds
> > TestRunner_userchan-tester    PASS      20.61 seconds
> > TestRunner_6lowpan-tester     PASS      24.04 seconds
> > IncrementalBuild              PASS      29.81 seconds
> >
> > Details
> > ##############################
> > Test: CheckKernelLLVM - SKIP
> > Desc: Build kernel with LLVM + context analysis
> > Output:
> > Clang not found
> > ##############################
> > Test: TestRunner_mgmt-tester - FAIL
> > Desc: Run mgmt-tester with test-runner
> > Output:
> > Total: 501, Passed: 496 (99.0%), Failed: 1, Not Run: 4
> >
> > Failed Test Cases
> > Read Exp Feature - Success                           Failed       0.252 seconds
> > ##############################
> > Test: TestRunner_mesh-tester - FAIL
> > Desc: Run mesh-tester with test-runner
> > Output:
> > Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
> >
> > Failed Test Cases
> > Mesh - Send cancel - 1                               Timed out    2.102 seconds
> > Mesh - Send cancel - 2                               Timed out    1.984 seconds
>
> I'm seeing the exact same failures in other CI runs from recent
> patches, e.g. :
>
> https://lore.kernel.org/linux-bluetooth/20260808062541.3705446-1-zhangchen200426@163.com/T/#t
>
> So I'm assuming that these are pre-existing CI issues and
> not caused by this patch.

Yeah, don't worry about those, there is an issue found by sashiko that
perhaps we need to address:

https://sashiko.dev/#/patchset/20260811083730.71393-1-johannes.goede%40oss.qualcomm.com

> Regards,
>
> Hans
>
>
>


-- 
Luiz Augusto von Dentz

Re: [1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[johannes.goede]

Hi Luiz,

On 11-Aug-26 15:59, Luiz Augusto von Dentz wrote:
> Hi,
> 
> On Tue, Aug 11, 2026 at 7:05 AM <johannes.goede@oss.qualcomm.com> wrote:

<snip>

>> I'm seeing the exact same failures in other CI runs from recent
>> patches, e.g. :
>>
>> https://lore.kernel.org/linux-bluetooth/20260808062541.3705446-1-zhangchen200426@163.com/T/#t
>>
>> So I'm assuming that these are pre-existing CI issues and
>> not caused by this patch.
> 
> Yeah, don't worry about those, there is an issue found by sashiko that
> perhaps we need to address:
> 
> https://sashiko.dev/#/patchset/20260811083730.71393-1-johannes.goede%40oss.qualcomm.com

Thank you for pointing that out.

The Sashiko suggestion to make the clearing of the flag unconditionally
(after freeing the skb if it is there) seems to make sense.

Shall I prepare a v2 with that change ?

Regards,

Hans

Re: [1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[Luiz Augusto von Dentz]

Hi Hans,

On Tue, Aug 11, 2026 at 10:43 AM <johannes.goede@oss.qualcomm.com> wrote:
>
> Hi Luiz,
>
> On 11-Aug-26 15:59, Luiz Augusto von Dentz wrote:
> > Hi,
> >
> > On Tue, Aug 11, 2026 at 7:05 AM <johannes.goede@oss.qualcomm.com> wrote:
>
> <snip>
>
> >> I'm seeing the exact same failures in other CI runs from recent
> >> patches, e.g. :
> >>
> >> https://lore.kernel.org/linux-bluetooth/20260808062541.3705446-1-zhangchen200426@163.com/T/#t
> >>
> >> So I'm assuming that these are pre-existing CI issues and
> >> not caused by this patch.
> >
> > Yeah, don't worry about those, there is an issue found by sashiko that
> > perhaps we need to address:
> >
> > https://sashiko.dev/#/patchset/20260811083730.71393-1-johannes.goede%40oss.qualcomm.com
>
> Thank you for pointing that out.
>
> The Sashiko suggestion to make the clearing of the flag unconditionally
> (after freeing the skb if it is there) seems to make sense.
>
> Shall I prepare a v2 with that change ?

Yes, please respin.

> Regards,
>
> Hans
>
>
>


-- 
Luiz Augusto von Dentz

Re: [PATCH 1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request

[patchwork-bot+bluetooth]

Hello:

This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Tue, 11 Aug 2026 10:37:29 +0200 you wrote:
> From: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com>
> 
> A synchronous HCI command that never receives a response leaves
> HCI_CMD_PENDING set: hci_req_cmd_complete() is the only place that clears
> it, and it only runs when a response matching the last command sent
> arrives.
> 
> [...]

Here is the summary with links:
  - [1/2] Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last request
    https://git.kernel.org/bluetooth/bluetooth-next/c/ed516e3f1aa6
  - [2/2] Bluetooth: hci_sync: Factor common cleanup code into a helper
    https://git.kernel.org/bluetooth/bluetooth-next/c/2fe8aa99af55

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html