Linux bluetooth development
 help / color / mirror / Atom feed
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


             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