From: Andrew Sayers <kernel.org@pileofstuff.org>
To: linux-bluetooth@vger.kernel.org
Cc: luiz.dentz@gmail.com, pav@iki.fi,
Andrew Sayers <kernel.org@pileofstuff.org>
Subject: [PATCH BlueZ v2 2/5] obexd/bluetooth: Support calling bluetooth_init() after bluetooth_exit()
Date: Fri, 25 Apr 2025 18:13:01 +0100 [thread overview]
Message-ID: <20250425171505.573271-3-kernel.org@pileofstuff.org> (raw)
In-Reply-To: <20250425171505.573271-1-kernel.org@pileofstuff.org>
bluetooth_exit() didn't previously unregister itself thoroughly. That
was fine if it was only called when the service was about to exit,
because everything was implicitly unregistered when the process ended.
But we need to be more scrupulous if this can be called throughout
the program's lifecycle.
Send UnregisterProfile messages directly from bluetooth_exit(),
then call unregister_profile(profile).
The UnregisterProfile message can't be sent directly from
unregister_profile(), because that also needs to be called when
register_profile() fails halfway through.
Do not free profiles in bluetooth_exit() - profiles are needed
by a future call to bluetooth_init(), or will be freed by
bluetooth_stop() if necessary.
Signed-off-by: Andrew Sayers <kernel.org@pileofstuff.org>
---
obexd/plugins/bluetooth.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/obexd/plugins/bluetooth.c b/obexd/plugins/bluetooth.c
index afb2215bd..8cf718922 100644
--- a/obexd/plugins/bluetooth.c
+++ b/obexd/plugins/bluetooth.c
@@ -440,12 +440,24 @@ static int bluetooth_init(void)
static void bluetooth_exit(void)
{
+ GSList *l;
+
g_dbus_remove_watch(connection, listener_id);
- g_slist_free_full(profiles, profile_free);
+ for (l = profiles; l; l = l->next) {
+ struct bluetooth_profile *profile = l->data;
+
+ if (profile->path == NULL)
+ continue;
+
+ unregister_profile(profile);
+ }
- if (connection)
+ if (connection) {
+ dbus_connection_close(connection);
dbus_connection_unref(connection);
+ connection = NULL;
+ }
obex_transport_driver_unregister(&driver);
}
--
2.49.0
next prev parent reply other threads:[~2025-04-25 17:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 17:12 [PATCH BlueZ v2 0/4] obexd: unregister profiles when the user is inactive Andrew Sayers
2025-04-25 17:13 ` [PATCH BlueZ v2 1/5] pbap: Support calling pbap_init() after pbap_exit() Andrew Sayers
2025-04-25 18:50 ` obexd: unregister profiles when the user is inactive bluez.test.bot
2025-04-25 17:13 ` Andrew Sayers [this message]
2025-04-25 17:13 ` [PATCH BlueZ v2 3/5] obexd: Support creating private system/session bus connections Andrew Sayers
2025-04-25 17:13 ` [PATCH BlueZ v2 4/5] obexd: Unregister profiles when the user is inactive Andrew Sayers
2025-04-25 17:13 ` [PATCH BlueZ v2 5/5] Revert "obexd: only run one instance at once" Andrew Sayers
2025-04-25 18:20 ` [PATCH BlueZ v2 0/4] obexd: unregister profiles when the user is inactive Luiz Augusto von Dentz
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=20250425171505.573271-3-kernel.org@pileofstuff.org \
--to=kernel.org@pileofstuff.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=pav@iki.fi \
/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