Hi Kiran,
> For NOP command, need to cancel work scheduled on cmd_timer,
> on receiving command status or commmand complete event.
>
> Below use case might lead to race condition multiple when NOP
> commands are queued sequentially:
>
> hci_cmd_work() {
> if (atomic_read(&hdev->cmd_cnt) {
> .
> .
> .
> atomic_dec(&hdev->cmd_cnt);
> hci_send_frame(hdev,...);
> schedule_delayed_work(&hdev->cmd_timer,...);
> }
> }
>
> On receiving event for first NOP, the work scheduled on hdev->cmd_timer
> is not cancelled and second NOP is dequeued and sent to controller.
>
> While waiting for an event for second NOP command, work scheduled on
> cmd_timer for the first NOP can get scheduled, resulting in sending third
> NOP command (sending back to back NOP commands). This might
> cause issues at controller side (like memory overrun, controller going
> unresponsive) resulting in hci tx timeouts, hardware errors etc.
>
> The fix to this issue is to cancel the delayed work scheduled on
> cmd_timer on receiving command status or command complete event for
> NOP command (this patch handles NOP command same as any other SIG
> command).
>
> Signed-off-by: Kiran K <kiran.k@xxxxxxxxx>
> Reviewed-by: Chethan T N <chethan.tumkur.narayan@xxxxxxxxx>
> Reviewed-by: Srivatsa Ravishankar <ravishankar.srivatsa@xxxxxxxxx>
> Acked-by: Manish Mandlik <mmandlik@xxxxxxxxxx>
> ---
> net/bluetooth/hci_event.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
