Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH BlueZ] shared/bap: Fix rejecting re-attach of the same fd
@ 2026-07-11  7:02 Ferose
  2026-07-11  8:34 ` [BlueZ] " bluez.test.bot
  2026-07-13 20:10 ` [PATCH BlueZ] " patchwork-bot+bluetooth
  0 siblings, 2 replies; 3+ messages in thread
From: Ferose @ 2026-07-11  7:02 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Luiz Augusto von Dentz, Ferose

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


^ permalink raw reply related	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-07-13 20:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-11  7:02 [PATCH BlueZ] shared/bap: Fix rejecting re-attach of the same fd Ferose
2026-07-11  8:34 ` [BlueZ] " bluez.test.bot
2026-07-13 20:10 ` [PATCH BlueZ] " patchwork-bot+bluetooth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox