tree 877ee3aec8a787462aa6c046d21a1b06ec7d4da5
parent 01ce9e4233561dc55e05389959ad9d5a5db25d44
author Pavlin Radoslavov <pavlin@google.com> 1489665261 -0700
committer Pavlin Radoslavov <pavlin@google.com> 1489692641 -0700

Fix an HCI race condition when transmitting a packet

There is a race condition when calling
event_command_ready() -> transmit_fragment() -> hci_transmit()

If right after hci_transmit() there is thread context switch
and another thread executes filter_incoming_event() for the same
command, the corresponding packet/command will be taken off the
commands_pending_response list and free()-ed.

However, after the execution on the first thread continues
within transmit_fragment(), the execution logic will continue using
the "packet" that was already free()-ed by the other thread.

To prevent this from happening, the "commands_pending_response_mutex"
within event_command_ready() has to protect the transmit_fragment()
execution and the update_command_response_timer() function right after it.

Also:
 * Changed the "commands_pending_response_mutex" to recursive_mutex
 * Added "commands_pending_response_mutex" protection in few other
   places where "commands_pending_response" itself is used.

Bug: 36205494
Test: Running ASAN build
Change-Id: I63677ad1f2b28683c321631e9e29e4f01628d269