Blob Blame History Raw
From: Niels Dossche <niels.dossche@ugent.be>
Date: Sun, 13 Feb 2022 00:14:30 +0100
Subject: Bluetooth: move adv_instance_cnt read within the device lock
Patch-mainline: v5.18-rc1
Git-commit: 4bd80d7a4039ac605a1e9ae767d2b01dbfc9b61e
References: jsc#PED-1407

The field adv_instance_cnt is always accessed within a device lock,
except in the function add_advertising. A concurrent remove of an
advertisement with adding another one could result in the if check
"if a new instance was actually added" to not trigger, resulting
in not triggering the "advertising added event".

Signed-off-by: Niels Dossche <niels.dossche@ugent.be>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Acked-by: Lee, Chun-Yi <jlee@suse.com>
---
 net/bluetooth/mgmt.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -8079,7 +8079,7 @@ static int add_advertising(struct sock *
 	u32 flags;
 	u8 status;
 	u16 timeout, duration;
-	unsigned int prev_instance_cnt = hdev->adv_instance_cnt;
+	unsigned int prev_instance_cnt;
 	u8 schedule_instance = 0;
 	struct adv_info *next_instance;
 	int err;
@@ -8130,6 +8130,8 @@ static int add_advertising(struct sock *
 		goto unlock;
 	}
 
+	prev_instance_cnt = hdev->adv_instance_cnt;
+
 	err = hci_add_adv_instance(hdev, cp->instance, flags,
 				   cp->adv_data_len, cp->data,
 				   cp->scan_rsp_len,