Hi Daniel, > This series addresses a race condition where an advertisement > registration can conflict with a software rotation advertisement > refresh. I found that this issue was only occurring with the new > extended MGMT advertising interface. A bad use of the > hdev->cur_adv_instance caused every new instance to be immediately sent > to the controller rather than queued for software rotation, opening a > path for the race to occur. > > This series improves the way new extended advertising hci callbacks > track the relevant adv handle, removing the need for the > cur_adv_instance use. In a separate patch, the incorrect usage of > cur_adv_instance is removed, to align the extended MGMT commands to the > original add_advertising usage. The series was tested on both extended > and non-extended bluetooth controllers to confirm that the race > condition is resolved, and that multi- and single-advertising automated > test scenarios are still successful. > > Thanks in advance, > Daniel > > > Daniel Winkler (2): > Bluetooth: Use ext adv handle from requests in CCs > Bluetooth: Do not set cur_adv_instance in adv param MGMT request > > net/bluetooth/hci_event.c | 16 +++++++--------- > net/bluetooth/mgmt.c | 1 - > 2 files changed, 7 insertions(+), 10 deletions(-) both patches have been applied to bluetooth-next tree. Regards Marcel
