From: Ferose <ferose2@gmail.com>
To: linux-bluetooth@vger.kernel.org
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>,
Ferose <ferose2@gmail.com>
Subject: [PATCH BlueZ] shared/bap: Fix rejecting re-attach of the same fd
Date: Sat, 11 Jul 2026 00:02:30 -0700 [thread overview]
Message-ID: <20260711070230.26553-1-ferose2@gmail.com> (raw)
When the remote's STREAMING ASE notification arrives before
iso_connect_cb() fires, the race handler in bap_state()
(profiles/audio/bap.c) already attaches the io to the stream; the
comment there notes "Order of STREAMING and iso_connect_cb() is
nondeterministic". When iso_connect_cb() then calls
bt_bap_stream_set_io() with the same fd, the guard in
bap_ucast_set_io() sees an attached, non-connecting io and returns
false. iso_connect_cb() treats that as fatal:
profiles/audio/bap.c:iso_connect_cb() Unable to set IO
profiles/audio/transport.c:bap_state_changed() Unable to get stream IO
and tears down a CIS that btmon shows was established successfully
(CIS Established status 0, both ISO data paths set up). With a device
whose STREAMING notifications consistently win the race, streaming is
never possible.
Treat re-attaching the fd that is already attached as a no-op success,
without re-running the per-stream state actions (which would send a
duplicate Receiver Start Ready to a linked source ASE). Attaching a
different fd to a non-connecting io remains an error.
Fixes: https://github.com/bluez/bluez/issues/2223
---
src/shared/bap.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/shared/bap.c b/src/shared/bap.c
index db6f4f2..1660b8b 100644
--- a/src/shared/bap.c
+++ b/src/shared/bap.c
@@ -2589,9 +2589,18 @@ static unsigned int bap_bcast_release(struct bt_bap_stream *stream,
static bool bap_ucast_set_io(struct bt_bap_stream *stream, int fd)
{
- if (!stream || (fd >= 0 && stream->io && !stream->io->connecting))
+ if (!stream)
return false;
+ /*
+ * The STREAMING state handler may already have attached this io
+ * if the remote's ASE notification raced ahead of iso_connect_cb
+ * (see bap_state() in profiles/audio/bap.c). Re-attaching the
+ * same fd is a no-op success; only a different fd is an error.
+ */
+ if (fd >= 0 && stream->io && !stream->io->connecting)
+ return stream_io_get_fd(stream->io) == fd;
+
bap_stream_set_io(stream, INT_TO_PTR(fd));
queue_foreach(stream->links, bap_stream_set_io, INT_TO_PTR(fd));
--
2.50.1
next reply other threads:[~2026-07-11 7:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-11 7:02 Ferose [this message]
2026-07-11 8:34 ` [BlueZ] shared/bap: Fix rejecting re-attach of the same fd bluez.test.bot
2026-07-13 20:10 ` [PATCH BlueZ] " patchwork-bot+bluetooth
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=20260711070230.26553-1-ferose2@gmail.com \
--to=ferose2@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.von.dentz@intel.com \
/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