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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.