usb: hold lock throughout resample handler

Rather than acquiring the lock twice, lock it once and hold it while
doing the check and potential follow-up call to interrupt().  This looks
like it could be a race to me, but I don't know if it can actually cause
problems in practice.  In any case, it's better to only acquire the lock
once.

BUG=chromium:831850
TEST=Test adb in Crostini

Change-Id: Id7aa76e543cd5b858faf128f516e8d63e27cf3e7
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1592579
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>

1 files changed, 3 insertions, 2 deletions

diff --git a/devices/src/usb/xhci/intr_resample_handler.rs b/devices/src/usb/xhci/intr_resample_handler.rs
index 91dd46a..a2a40bb 100644
--- a/devices/src/usb/xhci/intr_resample_handler.rs
+++ b/devices/src/usb/xhci/intr_resample_handler.rs
@@ -47,13 +47,14 @@ impl EventHandler for IntrResampleHandler {
             }
         }
         usb_debug!("resample triggered");
-        if !self.interrupter.lock().event_ring_is_empty() {
+        let mut interrupter = self.interrupter.lock();
+        if !interrupter.event_ring_is_empty() {
             usb_debug!("irq resample re-assert irq event");
             // There could be a race condition. When we get resample_evt and other
             // component is sending interrupt at the same time.
             // This might result in one more interrupt than we want. It's handled by
             // kernel correctly.
-            if let Err(e) = self.interrupter.lock().interrupt() {
+            if let Err(e) = interrupter.interrupt() {
                 error!("cannot send interrupt: {}", e);
                 return Err(());
             }