[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210405233305.92431-1-danielwinkler@google.com>
Date: Mon, 5 Apr 2021 16:33:03 -0700
From: Daniel Winkler <danielwinkler@...gle.com>
To: marcel@...tmann.org, linux-bluetooth@...r.kernel.org
Cc: chromeos-bluetooth-upstreaming@...omium.org,
Daniel Winkler <danielwinkler@...gle.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Johan Hedberg <johan.hedberg@...il.com>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: [PATCH 0/2] Bluetooth: Avoid centralized adv handle tracking for
extended features
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
Powered by blists - more mailing lists