[PATCH crosvm 1/2] sys_util: make UnixSeqpacket::recv use libc::recv

Alyssa Ross
2020-07-06T16:01:50Z

It's very surprising that a method called "recv" would end up calling
read(). When UnixSeqpacket was introduced in 1d44223f9, the method
was called "read", so this behaviour made more sense. It was renamed
to "recv" in b7196e2a1, but the implementation was not changed to call
libc::recv.

In most cases, according to recv(2), the difference between read() and
recv() doesn't matter:

> The only difference between recv() and read(2) is the presence of
> flags. With a zero flags argument, recv() is generally equivalent
> to read(2) (but see NOTES).

But the NOTES section explains that

> If a zero-length datagram is pending, read(2) and recv() with a
> flags argument of zero provide different behavior. In this
> circumstance, read(2) has no effect (the datagram remains pending),
> while recv() consumes the pending datagram.

This means that, while we might expect UnixSeqpacket::recv(&mut []) to
mirror the behaviour of recv() and discard a message despite the empty
buffer, it would actually leave it there. This became relevant when I
implemented the startup message queue in 5bd2e7f60, because I used an
empty recv to drop the ready message from the socket, since it was
only used for polling and I didn't care about the content. But, it
turns out that my UnixSeqpacket::recv call did nothing, and left the
message on the socket. This wasn't immediately noticeable, but it
meant that when a message came through on the control socket later,
it would actually get the ready message from UnixSeqpacket::recv,
rather than the expected message on the control socket.

For example, trying to use crosvm disk resize would print a message
like the following:

> [ERROR:vm_control/src/lib.rs:649] unexpected disk socket result: Ready
> [ERROR:devices/src/virtio/block.rs:334] Attempted to resize read-only block device

We can see that it does try to process the received message, but first
it tries to do something with the Ready message, which should have
been discarded by now.

With this fix applied, we can see that it now receives and tries to
process the correct message (but then fails because the VM I tested
didn't support disk resizing!):

> [ERROR:devices/src/virtio/block.rs:334] Attempted to resize read-only block device

Fixes: b7196e2a1c1eb7123e7eace5418b7eb4a3e24dbe
Fixes: 5bd2e7f606b726b598fdc26fe26a9b4029fab6d3
Cc: Cole Helbling <cole.e.helbling@outlook.com>
---
This is the fix I described in This Week in Spectrum[1].

[1]: https://spectrum-os.org/lists/archives/spectrum-discuss/8736654ij2.fsf@alyssa.is/

sys_util/src/net.rs | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sys_util/src/net.rs b/sys_util/src/net.rs
index 71ab3eeb5..82b4f5bb0 100644
--- a/sys_util/src/net.rs
+++ b/sys_util/src/net.rs
@@ -197,7 +197,7 @@ impl UnixSeqpacket {
}
}

- /// Read data from the socket fd to a given buffer
+ /// Receive data from the socket fd to a given buffer.
///
/// # Arguments
/// * `buf` - A mut reference to the data buffer.
@@ -206,11 +206,11 @@ impl UnixSeqpacket {
/// * `usize` - The size of bytes read to the buffer.
///
/// # Errors
- /// Returns error when `libc::read` failed.
+ /// Returns error when `libc::recv` failed.
pub fn recv(&self, buf: &mut [u8]) -> io::Result<usize> {
// Safe since we make sure the input `count` == `buf.len()` and handle the returned error.
unsafe {
- let ret = libc::read(self.fd, buf.as_mut_ptr() as *mut _, buf.len());
+ let ret = libc::recv(self.fd, buf.as_mut_ptr() as *mut _, buf.len(), 0);
if ret < 0 {
Err(io::Error::last_os_error())
} else {
--
2.26.2