shared/bap: Fix rejecting re-attach of the same fd

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.

---
 src/shared/bap.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

index db6f4f2..1660b8b 100644
@@ -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

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1125740

---Test result---

Test Summary:

CheckPatch                    PASS      0.48 seconds
GitLint                       PASS      0.33 seconds
BuildEll                      PASS      20.21 seconds
BluezMake                     PASS      542.83 seconds
MakeCheck                     PASS      12.74 seconds
MakeDistcheck                 PASS      157.54 seconds
CheckValgrind                 PASS      204.16 seconds
CheckSmatch                   WARNING   306.24 seconds
bluezmakeextell               PASS      100.48 seconds
IncrementalBuild              PASS      538.46 seconds
ScanBuild                     PASS      964.22 seconds

Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/shared/bap.c:318:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:318:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:318:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures

https://github.com/bluez/bluez/pull/2298

---
Regards,
Linux Bluetooth