vsock: fixed TX buf flushing

This patch has been cherry-picked from the Firecracker tree. The
reference commit is 78819f35f63f5777a58e3e1e774b3270b32881ed.

The vsock TX buffer flush operation would report inconsistent results,
under specific circumstances.

The flush operation is performed in two steps, since it's dealing with a
ring buffer, an the data to be flushed may wrap around. If the first
step was successful, but the second one failed, the whole flush
operation would report an error, thus causing flow control accounting to
lose track of the bytes that were successfully written by the first
pass.

This commit changes the flush behavior to always report success when
some data has been written to the backing stream.

Signed-off-by: Dan Horobeanu <dhr@amazon.com>
Signed-off-by: Gabriel Ionescu <gbi@amazon.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>

vm-virtio/src/vsock/csm/txbuf.rs

@@ -138,7 +138,11 @@ impl TxBuf {
         // Attempt our second write. This will return immediately if a second write isn't
         // needed, since checking for an empty buffer is the first thing we do in this
         // function.
-        Ok(written + self.flush_to(sink)?)
+        //
+        // Interesting corner case: if we've already written some data in the first pass,
+        // and then the second write fails, we will consider the flush action a success
+        // and return the number of bytes written in the first pass.
+        Ok(written + self.flush_to(sink).unwrap_or(0))
     }
 
     /// Check if the buffer holds any data that hasn't yet been flushed out.