[PATCH] Bluetooth: drop the pending command if the adv monitor queue fails

[PATCH] Bluetooth: drop the pending command if the adv monitor queue fails

[Wentao Liang]

__add_adv_patterns_monitor() links the command into hdev->mgmt_pending,
which takes a reference on the socket, and then queues the sync work.
When hci_cmd_sync_queue() fails, for example because the controller is
not running or is being unregistered, the work never runs and the
completion callback that would free the command is never invoked. The
command therefore stays on the pending list and keeps the socket
reference until the controller is unregistered, and it also keeps
MGMT_OP_ADD_ADV_PATTERNS_MONITOR busy for other requests.

Remove the pending command on the queue failure path, matching what the
other management commands do when their queueing fails.

Fixes: b747a83690c8 ("Bluetooth: hci_sync: Refactor add Adv Monitor")
Cc: stable@vger.kernel.org
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
 net/bluetooth/mgmt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 3b9c82bd2f02..282ce65f19eb 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -5542,6 +5542,7 @@ static int __add_adv_patterns_monitor(struct sock *sk, struct hci_dev *hdev,
 		else
 			status = MGMT_STATUS_FAILED;
 
+		mgmt_pending_remove(cmd);
 		goto unlock;
 	}
 
-- 
2.34.1

Re: [PATCH] Bluetooth: drop the pending command if the adv monitor queue fails

[Krzysztof Kozlowski]

On Wed, 04 Nov 2026 02:28:08 +0000, Wentao Liang wrote:
> __add_adv_patterns_monitor() links the command into hdev->mgmt_pending,
> which takes a reference on the socket, and then queues the sync work.
> When hci_cmd_sync_queue() fails, for example because the controller is
> not running or is being unregistered, the work never runs and the
> completion callback that would free the command is never invoked. The
> command therefore stays on the pending list and keeps the socket
> reference until the controller is unregistered, and it also keeps
> MGMT_OP_ADD_ADV_PATTERNS_MONITOR busy for other requests.
> 
> Remove the pending command on the queue failure path, matching what the
> other management commands do when their queueing fails.
> 
> Fixes: b747a83690c8 ("Bluetooth: hci_sync: Refactor add Adv Monitor")
> Cc: stable@vger.kernel.org
> Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
>  net/bluetooth/mgmt.c | 1 +
>  1 file changed, 1 insertion(+)
> 

Multiple things here:
1. Your team ignored completely previous feedback. Multiple times.

2. You use multiple identities with this email address, thus I doubt that we
   speak with an actual person.

3. Your bot does not even bother running checkpatch, right?

4. Nothing of this was reproduced nor tested.

5. Finally, the same feedback:
You sent multiple independent patches, to multiple independent
subsystems. The amount of these patches clearly suggest this was
AI generated and most likely not tested.

More importantly, you sent all this work without properly organizing
relevant patches into patchsets. This makes reviewing difficult
and might cause multiple reviewers to address the same issue.
Replying to the entire set is impossible and requires handling each
patch independently, instead of applying or discarding the set.
Maintainers also won't see the bigger picture of your work. Quite
worrying.

This is on the verge of hostile patch: bomb us with so many
contributions, we won't be able to handle them in efficient manner,
like responding ONCE to ask you to slow down.  Considering all this
is untested and LLM generated, I have even more doubts whether this
should be considered for review.

Please read kernel documentation BEFORE posting more work. It will
explain you how to identify subsystems, how to organize your work per
subsystem (so a patchset grouping multiple patches with a short cover
letter), how to document the issue discovery method and what was
or was not tested.

Best regards,
Krzysztof

RE: Bluetooth: drop the pending command if the adv monitor queue fails

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2279 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/series/1201152/

---Test result---

Test Summary:
CheckPatch                    FAIL      0.55 seconds
VerifyFixes                   PASS      0.09 seconds
VerifySignedoff               PASS      0.09 seconds
GitLint                       PASS      0.24 seconds
SubjectPrefix                 PASS      0.09 seconds
BuildKernel                   PASS      23.23 seconds
CheckAllWarning               PASS      27.81 seconds
CheckSparse                   PASS      28.90 seconds
BuildKernel32                 PASS      23.85 seconds
CheckKernelLLVM               PASS      24.02 seconds
TestRunnerSetup               PASS      552.79 seconds
TestRunner_mgmt-tester        PASS      94.70 seconds
TestRunner_mesh-tester        FAIL      10.57 seconds
IncrementalBuild              PASS      23.01 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: drop the pending command if the adv monitor queue fails
WARNING: Non-standard signature: Assisted-by:
#96: 
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex

ERROR: Unrecognized email address: 'DeepSeek-V4.1-Flash and OpenAI Codex'
#96: 
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex

total: 1 errors, 1 warnings, 0 checks, 7 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

/home/runner/work/bluetooth-next/bluetooth-next/src/patch/14942648.patch has style problems, please review.

NOTE: Ignored message types: UNKNOWN_COMMIT_ID

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.


##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 9 (90.0%), Failed: 1, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Failed       0.023 seconds


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

---
Regards,
Linux Bluetooth