We can't do synchronous HCI command sending in any settings commit()
callback, since we don't know what context the callback is being called
from. One particular deadlock can happen if settings_load() is called from
the preemptible main thread:
main()
|--> settings_load() (aquire settings_lock mutex)
|-->commit callback A that defers to system wq
|-->commit callback B that calls bt_hci_cmd_send_sync()
system wq from the previous deferral from within settings_load():
|--> work item
|--> settings_save_one()
|--> attempt to aquire settings_lock mutex
In the above scenario, the bt_hci_cmd_send_sync() call from the main thread
depends on the system workqueue being processed (since that's what does HCI
command processing by default), while at the same time holding the settings
subsystem's mutex. At the same time, a system wq item tries to store
something into settings, however it deadlocks waiting for the settings
mutex.
The actual scenario that we have in the Bluetooth subsystem is where
"commit callback A" is commit_settings() in host/settings.c, and "commit
callback B" is keys_commit() in host/keys.c.
The solution to the deadlock is to take advantage of deferred bt_id_add()
handling which already exists, i.e. set a flag and deferre the actual
adding to the system workqueue.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Call the RPA expired callback on advertising sets even when they are
not enabled.
The RPA expired callback will now be called on advertising sets
when the BT_ADV_RPA_VALID flag is cleared for the set.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Update the RPA timer to the new delayable work API.
Checking for submitted RPA timer no longer needed with the schedule
function, which does not change the deadline.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Refactor out the identity handling from hci_core to its own source file
in id.c
Identity consistes of managing the identities of the device, the privacy
feature which hides the identities. And handling of the identity
resolving list in the controller, needed to support privacy-enabled
remote devices.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
