From: Wei Deng <wei.deng@oss.qualcomm.com>
To: openembedded-core@lists.openembedded.org
Cc: yoann.congal@smile.fr, cheng.jiang@oss.qualcomm.com,
shuai.zhang@oss.qualcomm.com, mengshi.wu@oss.qualcomm.com,
jinwang.li@oss.qualcomm.com, xiuzhuo.shang@oss.qualcomm.com
Subject: [PATCH 3/4] bluez5: fix gatt cache sync issue
Date: Fri, 26 Jun 2026 12:12:32 +0530 [thread overview]
Message-ID: <20260626064233.704350-4-wei.deng@oss.qualcomm.com> (raw)
In-Reply-To: <20260626064233.704350-1-wei.deng@oss.qualcomm.com>
From: Mengshi Wu <mengshi.wu@oss.qualcomm.com>
There is a timing issue to update DB Hash value.
The gatt_client_service_changed() callback in src/device.c
is called from service_changed_complete() in gatt-client.c,
which is invoked after db_hash_read_cb() has already updated
the hash. Adding store_gatt_db(device) here guarantees the
db is persisted with the correct, up-to-date hash for both
the addition and removal cases.
Upstream-Status: Backport [bluez/bluez@0fd01e9]
Signed-off-by: Mengshi Wu <mengshi.wu@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
...x-stored-gatt-cache-DB-Hash-value-no.patch | 84 +++++++++++++++++++
2 files changed, 85 insertions(+)
create mode 100644 meta/recipes-connectivity/bluez5/bluez5/0001-src-device-Fix-stored-gatt-cache-DB-Hash-value-no.patch
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 1600107b878..4e51cc9a213 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -73,6 +73,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
file://0001-gatt-client-Fix-use-after-free-caused-by-reentrant-c.patch \
file://0001-transport-Fix-set-volume-failure-with-invalid-device.patch \
file://0001-advertising-Fix-sending-extra-bytes-with-MGMT_OP_ADD.patch \
+ file://0001-src-device-Fix-stored-gatt-cache-DB-Hash-value-no.patch \
"
S = "${UNPACKDIR}/bluez-${PV}"
diff --git a/meta/recipes-connectivity/bluez5/bluez5/0001-src-device-Fix-stored-gatt-cache-DB-Hash-value-no.patch b/meta/recipes-connectivity/bluez5/bluez5/0001-src-device-Fix-stored-gatt-cache-DB-Hash-value-no.patch
new file mode 100644
index 00000000000..69323bdc5ee
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/0001-src-device-Fix-stored-gatt-cache-DB-Hash-value-no.patch
@@ -0,0 +1,84 @@
+From 9ec8cad56e47c0555a056e928e6568d543b3ae0c Mon Sep 17 00:00:00 2001
+From: Mengshi Wu <mengshi.wu@oss.qualcomm.com>
+Date: Wed, 1 Apr 2026 19:30:04 +0800
+Subject: [PATCH v1] src/device: Fix stored gatt cache DB Hash value not update
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+There is an asymmetry in behavior: when services are added during
+the same connection (via Service Changed indication), the persistent
+storage (disk) is not updated with the new DB hash, but when services
+are removed, it is updated.
+
+During the same connection, We check DB hash value stored at
+/var/lib/bluetooth/<adaptor addr>/cache/<remote addr>.
+When established connection, the stored DB Hash value is A.Then we
+add new services, the stored DB Hash value is still A which should
+change to B. However, if we remove the existing services, the stored
+DB Hash value changed to C.
+
+When performing addition, it goes like this:
+
+discover_primary_cb()
+ └─> gatt_db_insert_service() ← NEW service inserted into db
+ └─> gatt_service_added() ← callback fires immediately
+ └─> store_gatt_db() ← SAVED TO DISK (hash still OLD)
+ ...
+ └─> discovery_op_complete(success=true)
+ └─> read_db_hash(op) ← sends ATT Read By Type
+ └─> [ATT response arrives]
+ └─> db_hash_read_cb()
+ ├─> gatt_db_attribute_write(op->hash, ...)
+ │ └─> hash UPDATED IN MEMORY
+ └─> discovery_op_complete(true, 0)
+ ├─> [no services to remove, no
+ │ store_gatt_db called]
+ └─> service_changed_complete()
+
+Whereas removal perform like this:
+discovery_op_complete(success=true) [1st call]
+ └─> read_db_hash(op)
+ └─> op->hash is NULL → sends ATT request → early return
+...
+[ATT response arrives]
+db_hash_read_cb()
+ └─> gatt_db_attribute_write(op->hash, ) ← hash UPDATED IN MEMORY
+ └─> discovery_op_complete(true, 0) [2nd call]
+ └─> read_db_hash(op) → op->hash already set → returns false
+ └─> gatt_db_remove_service()
+ └─> gatt_service_removed()
+ └─> store_gatt_db() ← SAVED TO DISK (hash is NEW)
+
+There is a timing issue to update DB Hash value.
+
+The gatt_client_service_changed() callback in src/device.c is called
+from service_changed_complete() in gatt-client.c, which is invoked
+after db_hash_read_cb() has already updated the hash. Adding
+store_gatt_db(device) here guarantees the db is persisted with the
+correct, up-to-date hash for both the addition and removal cases.
+
+Upstream-Status: Backport [https://github.com/bluez/bluez/commit/0fd01e98cf94616a5c1c39749314cdd4a1654687]
+Signed-off-by: Mengshi Wu <mengshi.wu@oss.qualcomm.com>
+---
+ src/device.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/src/device.c b/src/device.c
+index 3ea683667..cfbde307b 100644
+--- a/src/device.c
++++ b/src/device.c
+@@ -6267,7 +6267,11 @@ static void gatt_client_service_changed(uint16_t start_handle,
+ uint16_t end_handle,
+ void *user_data)
+ {
++ struct btd_device *device = user_data;
++
+ DBG("start 0x%04x, end: 0x%04x", start_handle, end_handle);
++
++ store_gatt_db(device);
+ }
+
+ static void gatt_debug(const char *str, void *user_data)
+--
+2.34.1
--
2.34.1
next prev parent reply other threads:[~2026-06-26 6:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 6:42 [PATCH 0/4] bluez5: backport fixes from master to wrynose Wei Deng
2026-06-26 6:42 ` [PATCH 1/4] bluez5: fix set volume failure Wei Deng
2026-06-26 6:42 ` [PATCH 2/4] bluez5: Fix sending extra bytes with MGMT_OP_ADD_EXT_ADV_DATA Wei Deng
2026-06-26 6:42 ` Wei Deng [this message]
2026-06-26 6:42 ` [PATCH 4/4] bluez5: set L2CAP IMTU for OBEX profile listeners Wei Deng
2026-06-26 8:18 ` [PATCH 0/4] bluez5: backport fixes from master to wrynose Yoann Congal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260626064233.704350-4-wei.deng@oss.qualcomm.com \
--to=wei.deng@oss.qualcomm.com \
--cc=cheng.jiang@oss.qualcomm.com \
--cc=jinwang.li@oss.qualcomm.com \
--cc=mengshi.wu@oss.qualcomm.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=shuai.zhang@oss.qualcomm.com \
--cc=xiuzhuo.shang@oss.qualcomm.com \
--cc=yoann.congal@smile.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox