All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work
@ 2022-03-02  6:43 Luiz Augusto von Dentz
  2022-03-02  7:26 ` bluez.test.bot
  2022-03-02 14:37 ` Marcel Holtmann
  0 siblings, 2 replies; 3+ messages in thread
From: Luiz Augusto von Dentz @ 2022-03-02  6:43 UTC (permalink / raw)
  To: linux-bluetooth

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

The could be multiple hci_cmd_sync_work_entry enqueued when
hci_cmd_sync_work is executed so this makes sure they are all
dequeued properly.

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
 net/bluetooth/hci_sync.c | 65 ++++++++++++++++++++++++----------------
 1 file changed, 39 insertions(+), 26 deletions(-)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index d146d4efae43..724d34bdd62a 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -273,43 +273,56 @@ int __hci_cmd_sync_status(struct hci_dev *hdev, u16 opcode, u32 plen,
 }
 EXPORT_SYMBOL(__hci_cmd_sync_status);
 
-static void hci_cmd_sync_work(struct work_struct *work)
+
+static void hci_cmd_sync_work_entry_run(struct hci_dev *hdev,
+					struct hci_cmd_sync_work_entry *entry)
 {
-	struct hci_dev *hdev = container_of(work, struct hci_dev, cmd_sync_work);
-	struct hci_cmd_sync_work_entry *entry;
 	hci_cmd_sync_work_func_t func;
 	hci_cmd_sync_work_destroy_t destroy;
 	void *data;
+	int err;
 
-	bt_dev_dbg(hdev, "");
+	bt_dev_dbg(hdev, "entry %p", entry);
 
-	mutex_lock(&hdev->cmd_sync_work_lock);
-	entry = list_first_entry(&hdev->cmd_sync_work_list,
-				 struct hci_cmd_sync_work_entry, list);
-	if (entry) {
-		list_del(&entry->list);
-		func = entry->func;
-		data = entry->data;
-		destroy = entry->destroy;
-		kfree(entry);
-	} else {
-		func = NULL;
-		data = NULL;
-		destroy = NULL;
-	}
-	mutex_unlock(&hdev->cmd_sync_work_lock);
+	func = entry->func;
+	data = entry->data;
+	destroy = entry->destroy;
+	kfree(entry);
 
-	if (func) {
-		int err;
+	if (!func)
+		return;
+
+	hci_req_sync_lock(hdev);
+
+	err = func(hdev, data);
 
-		hci_req_sync_lock(hdev);
+	if (destroy)
+		destroy(hdev, data, err);
 
-		err = func(hdev, data);
+	hci_req_sync_unlock(hdev);
+}
 
-		if (destroy)
-			destroy(hdev, data, err);
+static void hci_cmd_sync_work(struct work_struct *work)
+{
+	struct hci_dev *hdev = container_of(work, struct hci_dev, cmd_sync_work);
+	struct hci_cmd_sync_work_entry *entry;
+
+	bt_dev_dbg(hdev, "");
+
+	while (1) {
+		mutex_lock(&hdev->cmd_sync_work_lock);
+		entry = list_first_entry_or_null(&hdev->cmd_sync_work_list,
+						 struct hci_cmd_sync_work_entry,
+						 list);
+		if (!entry) {
+			mutex_unlock(&hdev->cmd_sync_work_lock);
+			break;
+		}
+
+		list_del(&entry->list);
+		mutex_unlock(&hdev->cmd_sync_work_lock);
 
-		hci_req_sync_unlock(hdev);
+		hci_cmd_sync_work_entry_run(hdev, entry);
 	}
 }
 
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* RE: [RFC] Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work
  2022-03-02  6:43 [RFC] Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work Luiz Augusto von Dentz
@ 2022-03-02  7:26 ` bluez.test.bot
  2022-03-02 14:37 ` Marcel Holtmann
  1 sibling, 0 replies; 3+ messages in thread
From: bluez.test.bot @ 2022-03-02  7:26 UTC (permalink / raw)
  To: linux-bluetooth, luiz.dentz

[-- Attachment #1: Type: text/plain, Size: 2129 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=619444

---Test result---

Test Summary:
CheckPatch                    FAIL      1.66 seconds
GitLint                       PASS      0.99 seconds
SubjectPrefix                 PASS      0.89 seconds
BuildKernel                   PASS      30.15 seconds
BuildKernel32                 PASS      26.78 seconds
Incremental Build with patchesPASS      37.21 seconds
TestRunner: Setup             PASS      477.73 seconds
TestRunner: l2cap-tester      PASS      13.67 seconds
TestRunner: bnep-tester       PASS      6.09 seconds
TestRunner: mgmt-tester       PASS      105.01 seconds
TestRunner: rfcomm-tester     FAIL      7.68 seconds
TestRunner: sco-tester        PASS      7.80 seconds
TestRunner: smp-tester        PASS      7.68 seconds
TestRunner: userchan-tester   PASS      6.52 seconds

Details
##############################
Test: CheckPatch - FAIL - 1.66 seconds
Run checkpatch.pl script with rule in .checkpatch.conf
[RFC] Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work\CHECK:LINE_SPACING: Please don't use multiple blank lines
#99: FILE: net/bluetooth/hci_sync.c:276:
 
+

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

/github/workspace/src/12765538.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: rfcomm-tester - FAIL - 7.68 seconds
Run test-runner with rfcomm-tester
Total: 10, Passed: 9 (90.0%), Failed: 1, Not Run: 0

Failed Test Cases
Basic RFCOMM Socket Client - Write 32k Success       Failed       0.155 seconds



---
Regards,
Linux Bluetooth


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work
  2022-03-02  6:43 [RFC] Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work Luiz Augusto von Dentz
  2022-03-02  7:26 ` bluez.test.bot
@ 2022-03-02 14:37 ` Marcel Holtmann
  1 sibling, 0 replies; 3+ messages in thread
From: Marcel Holtmann @ 2022-03-02 14:37 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-bluetooth

Hi Luiz,

> The could be multiple hci_cmd_sync_work_entry enqueued when
> hci_cmd_sync_work is executed so this makes sure they are all
> dequeued properly.

might want to be a bit more verbose in the issue description.

> 
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> ---
> net/bluetooth/hci_sync.c | 65 ++++++++++++++++++++++++----------------
> 1 file changed, 39 insertions(+), 26 deletions(-)
> 
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index d146d4efae43..724d34bdd62a 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -273,43 +273,56 @@ int __hci_cmd_sync_status(struct hci_dev *hdev, u16 opcode, u32 plen,
> }
> EXPORT_SYMBOL(__hci_cmd_sync_status);
> 
> -static void hci_cmd_sync_work(struct work_struct *work)
> +
> +static void hci_cmd_sync_work_entry_run(struct hci_dev *hdev,
> +					struct hci_cmd_sync_work_entry *entry)
> {
> -	struct hci_dev *hdev = container_of(work, struct hci_dev, cmd_sync_work);
> -	struct hci_cmd_sync_work_entry *entry;
> 	hci_cmd_sync_work_func_t func;
> 	hci_cmd_sync_work_destroy_t destroy;
> 	void *data;
> +	int err;
> 
> -	bt_dev_dbg(hdev, "");
> +	bt_dev_dbg(hdev, "entry %p", entry);
> 
> -	mutex_lock(&hdev->cmd_sync_work_lock);
> -	entry = list_first_entry(&hdev->cmd_sync_work_list,
> -				 struct hci_cmd_sync_work_entry, list);
> -	if (entry) {
> -		list_del(&entry->list);
> -		func = entry->func;
> -		data = entry->data;
> -		destroy = entry->destroy;
> -		kfree(entry);
> -	} else {
> -		func = NULL;
> -		data = NULL;
> -		destroy = NULL;
> -	}
> -	mutex_unlock(&hdev->cmd_sync_work_lock);
> +	func = entry->func;
> +	data = entry->data;
> +	destroy = entry->destroy;
> +	kfree(entry);
> 
> -	if (func) {
> -		int err;
> +	if (!func)
> +		return;
> +
> +	hci_req_sync_lock(hdev);
> +
> +	err = func(hdev, data);
> 
> -		hci_req_sync_lock(hdev);
> +	if (destroy)
> +		destroy(hdev, data, err);
> 
> -		err = func(hdev, data);
> +	hci_req_sync_unlock(hdev);
> +}
> 
> -		if (destroy)
> -			destroy(hdev, data, err);
> +static void hci_cmd_sync_work(struct work_struct *work)
> +{
> +	struct hci_dev *hdev = container_of(work, struct hci_dev, cmd_sync_work);
> +	struct hci_cmd_sync_work_entry *entry;
> +
> +	bt_dev_dbg(hdev, "");
> +
> +	while (1) {
> +		mutex_lock(&hdev->cmd_sync_work_lock);
> +		entry = list_first_entry_or_null(&hdev->cmd_sync_work_list,
> +						 struct hci_cmd_sync_work_entry,
> +						 list);
> +		if (!entry) {
> +			mutex_unlock(&hdev->cmd_sync_work_lock);
> +			break;
> +		}
> +
> +		list_del(&entry->list);
> +		mutex_unlock(&hdev->cmd_sync_work_lock);
> 
> -		hci_req_sync_unlock(hdev);
> +		hci_cmd_sync_work_entry_run(hdev, entry);
> 	}
> }

In general I don’t like having two unlock vs one lock in the code. I know it is correct and the tools will also understand it is correct, but I just dislike it. I think it makes it hard for human eyes to verify locking balance.

I would prefer something like this:

	while (1) {
		struct hci_cmd_sync_work_entry *entry;
		int err;

		mutex_lock(&hdev->cmd_sync_work_lock);
		entry = list_first_entry_or_null(&hdev->cmd_..
		if (entry)
			list_del(&entry->list);
		mutex_unlock(&hdev->cmd_sync_work_lock);

		if (!entry)
			break;

		bt_dev_dbg(hdev, "entry %p", entry);

		if (entry->func) {
			hci_req_sync_lock(hdev);
			err = func(hdev, entry->data);
			if (entry->destroy)
				entry->destroy(hdev, entry->data, err);
			hci_req_sync_unlock(hdev);
		}

		kfree(entry);
	}

This looks a lot easy to read and verify to me.

Regards

Marcel


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-03-02 14:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-02  6:43 [RFC] Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work Luiz Augusto von Dentz
2022-03-02  7:26 ` bluez.test.bot
2022-03-02 14:37 ` Marcel Holtmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.