uvcvideo: Prevent new URBs being processed at stream stop

With asynchronous handling of the URBs from the USB Complete handler, we
get a continual stream of packets being received while we are attempting
to shutdown the stream.

Packets that have already been received and processed are on a
work-queue, but during stream shutdown the URBs that those packets
belong to are killed and free'd.

To prevent this race from causing invalid memory accesses, prevent new
URBs from being processed when uvc_stop_streaming() is called by
introducing a new flag "UVC_QUEUE_STOPPING" into the queue, and checking
this when processing the URB to be queued.

With this, we can flush the work queue, and commence a normal pipe
shutdown. Work tasks that are already queued are processed, but the URBs
are prevented from being re-submitted to the USB stack.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>

---

v2:
 - Re work critical sections for potential race

v3:
 - Previous rework was incorrect - and caused a deadlock.
 - Ensure that URB's are not resubmitted during work processing
    (This causes USB core error reports)
 - clear stopping flag bit after the stream is disabled.

v4:
 - use spin_lock_irq rather than spin_lock_irqsave() when not in
   interrupt contexts
 - URB's -> URBs
 - uvc_video_decode_data_work() - Protect access to flag with lock
 - uvc_video_complete(): Check stopping status after URB status handling

v5:
 - Fix up minor spacing issues

v6:
 - Fix another race as highlighted by Guennadi

v7:
 - Fix another race in uvc_video_complete().
 - Submit URBs with no asynchronous work in complete context.
3 files changed