Don't prematurely fake transmit responses

If the device is being ejected then the backend state will transition from
XenbusStateConnected to XenbusStateClosing. This is done by the toolstack
and should have no effect on the backend's ability to complete requests.
Therefore, when we fake responses in __TransmitterRingDisable() we could
be racing with an active backend. Hence amend the test in the loop to
consider a backend in either XenbusStateConnected or XenbusStateClosing to
be worth waiting for.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>

diff --git a/src/xenvif/transmitter.c b/src/xenvif/transmitter.c
index fefa712b281bd40b6de88eaa9938fe69a2f3ec45..9736d8119f8dfab3ecaa27c4ffde10487db118ee 100644 (file)
--- a/src/xenvif/transmitter.c
+++ b/src/xenvif/transmitter.c
@@ -3933,6 +3933,7 @@ __TransmitterRingDisable(
     PCHAR                           Buffer;
     XenbusState                     State;
     ULONG                           Attempt;
+    BOOLEAN                         WaitForBackend;
     NTSTATUS                        status;
 
     Transmitter = Ring->Transmitter;
@@ -3985,6 +3986,13 @@ __TransmitterRingDisable(
                      Buffer);
     }
 
+    //
+    // If the we are disabling during an eject then the backend will still be
+    // be there, but it will be in XenbusStateClosing state, not
+    // XenbusStateConnected.
+    //
+    WaitForBackend = (State == XenbusStateConnected) || (State == XenbusStateClosing);
+
     Attempt = 0;
     ASSERT3U(Ring->RequestsPushed, ==, Ring->RequestsPosted);
     while (Ring->ResponsesProcessed != Ring->RequestsPushed) {
@@ -3996,7 +4004,7 @@ __TransmitterRingDisable(
         __TransmitterRingSend(Ring);
         (VOID) TransmitterRingPoll(Ring);
 
-        if ((Attempt >= 100) || (State != XenbusStateConnected))
+        if ((Attempt >= 100) || !WaitForBackend)
             break;
 
         // We are waiting for a watch event at DISPATCH_LEVEL so