Hi Maintainers, 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(-) -- 2.31.0.208.g409f899ff0-goog
