Hi Niels, > Both hci_find_adv_instance and hci_remove_adv_instance have a comment > above their function definition saying that these two functions require > the caller to hold the hdev->lock lock. However, hci_le_ext_adv_term_evt > does not acquire that lock and neither does its caller hci_le_meta_evt > (hci_le_meta_evt calls hci_le_ext_adv_term_evt via an indirect function > call because of the lookup in hci_le_ev_table). > > The other event handlers all acquire and release the hdev->lock and they > follow the rule that hci_find_adv_instance and hci_remove_adv_instance > must be called while holding the hdev->lock lock. > > The solution is to make sure hci_le_ext_adv_term_evt also acquires and > releases the hdev->lock lock. The check on ev->status which logs a > warning and does an early return is not covered by the lock because > other functions also access ev->status without holding the lock. > > Signed-off-by: Niels Dossche <niels.dossche@xxxxxxxx> > --- > net/bluetooth/hci_event.c | 19 ++++++++++++------- > 1 file changed, 12 insertions(+), 7 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
