From 6ab4e247e60fd6bd1ccd079a2e2066c3f81f5d3c Mon Sep 17 00:00:00 2001 From: Stefano Garzarella Date: Tue, 16 Jun 2020 12:16:34 +0200 Subject: [PATCH] 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 Signed-off-by: Gabriel Ionescu Signed-off-by: Stefano Garzarella --- vm-virtio/src/vsock/csm/txbuf.rs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/vm-virtio/src/vsock/csm/txbuf.rs b/vm-virtio/src/vsock/csm/txbuf.rs index 1601b85ec..8e450b112 100644 --- a/vm-virtio/src/vsock/csm/txbuf.rs +++ b/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.