[PATCH] Bluetooth: free the mesh tx if queueing the send fails

[PATCH] Bluetooth: free the mesh tx if queueing the send fails

[Wentao Liang]

mesh_send() puts the new mesh_tx on hdev->mesh_pending through
mgmt_mesh_add(), which takes a socket reference, and only then queues
mesh_send_sync(). The cleanup on the failure path is guarded by
"sending", but that flag is set from HCI_MESH_SENDING before the queueing
and err is only ever set when it is clear: when sending is set no queueing
happens and no error is recorded. The guard is therefore never true on the
error path, so a failure of hci_cmd_sync_queue() leaves the mesh_tx on the
list with its socket reference held and no worker to consume it.

Drop the stale guard and always release the mesh_tx when the request
cannot be queued.

Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
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 | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 282ce65f19eb..067d4f5d961e 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2544,10 +2544,8 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
 		err = mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
 				      MGMT_STATUS_FAILED);
 
-		if (mesh_tx) {
-			if (sending)
-				mgmt_mesh_remove(mesh_tx);
-		}
+		if (mesh_tx)
+			mgmt_mesh_remove(mesh_tx);
 	} else {
 		hci_dev_set_flag(hdev, HCI_MESH_SENDING);
 
-- 
2.34.1

Re: [PATCH] Bluetooth: free the mesh tx if queueing the send fails

[Krzysztof Kozlowski]

On Wed, 04 Nov 2026 02:28:09 +0000, Wentao Liang wrote:
> mesh_send() puts the new mesh_tx on hdev->mesh_pending through
> mgmt_mesh_add(), which takes a socket reference, and only then queues
> mesh_send_sync(). The cleanup on the failure path is guarded by
> "sending", but that flag is set from HCI_MESH_SENDING before the queueing
> and err is only ever set when it is clear: when sending is set no queueing
> happens and no error is recorded. The guard is therefore never true on the
> error path, so a failure of hci_cmd_sync_queue() leaves the mesh_tx on the
> list with its socket reference held and no worker to consume it.
> 
> Drop the stale guard and always release the mesh_tx when the request
> cannot be queued.
> 
> Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
> 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 | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 

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: free the mesh tx if queueing the send fails

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2002 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/1201154/

---Test result---

Test Summary:
CheckPatch                    FAIL      2.32 seconds
VerifyFixes                   PASS      0.07 seconds
VerifySignedoff               PASS      0.33 seconds
GitLint                       PASS      0.22 seconds
SubjectPrefix                 PASS      0.06 seconds
BuildKernel                   PASS      32.95 seconds
CheckAllWarning               PASS      38.51 seconds
CheckSparse                   PASS      40.00 seconds
BuildKernel32                 PASS      32.80 seconds
CheckKernelLLVM               PASS      36.78 seconds
TestRunnerSetup               PASS      781.11 seconds
TestRunner_mgmt-tester        PASS      89.21 seconds
TestRunner_mesh-tester        PASS      5.96 seconds
IncrementalBuild              PASS      29.87 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: free the mesh tx if queueing the send fails
WARNING: Non-standard signature: Assisted-by:
#95: 
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex

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

total: 1 errors, 1 warnings, 0 checks, 12 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/14942650.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.




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

---
Regards,
Linux Bluetooth