From: "github-actions[bot]" <noreply@github.com>
To: linux-bluetooth@vger.kernel.org
Subject: [bluez/bluez] 9b0325: device: Recreate paired device from storage after ...
Date: Fri, 29 Aug 2025 02:57:10 -0700 [thread overview]
Message-ID: <bluez/bluez/push/refs/heads/996842/000000-9b0325@github.com> (raw)
Branch: refs/heads/996842
Home: https://github.com/bluez/bluez
Commit: 9b0325f0a941942cb4f3fe95e69c7f5c9e156ecf
https://github.com/bluez/bluez/commit/9b0325f0a941942cb4f3fe95e69c7f5c9e156ecf
Author: xinpeng.wang <wangxinpeng@uniontech.com>
Date: 2025-08-29 (Fri, 29 Aug 2025)
Changed paths:
M src/adapter.c
Log Message:
-----------
device: Recreate paired device from storage after failed restore
When a USB Bluetooth adapter is resumed from S4 suspend, the kernel
may trigger an "index remove" followed by an "index add". BlueZ
responds by removing all devices and attempting to recreate them
from stored configuration (storage).
However, if a connected A2DP device disconnects just before suspend,
BlueZ may have started a disconnect timer (via set_disconnect_timer)
but not yet freed the session. During this period:
- The session pointer is set to NULL and becomes inaccessible.
- The session still holds a reference to the device, preventing it
from being freed.
- As a result, the "index add" event fails to recreate the device from
storage (due to D-Bus path conflict or incomplete cleanup).
- Later, when the timer expires, a new device is created from discovery
data, bypassing storage and causing it to appear as unpaired.
This leads to loss of pairing information and confuses desktop applications
that rely on paired/unpaired state.
This patch enhances the device creation logic: if loading a paired device
from storage previously failed (e.g., due to pending session cleanup), its
address is recorded in the adapter's pending list. Later, when creating a
device from scan data, BlueZ checks this list and re-attempts creation from
storage if matched, ensuring the correct paired state is restored.
This ensures that devices are properly restored after suspend/resume
cycles, even in race conditions involving delayed session cleanup.
Signed-off-by: xinpeng.wang <wangxinpeng@uniontech.com>
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
reply other threads:[~2025-08-29 9:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bluez/bluez/push/refs/heads/996842/000000-9b0325@github.com \
--to=noreply@github.com \
--cc=linux-bluetooth@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).