From 372e910e6868950969ab74c5db046b7429efa615 Mon Sep 17 00:00:00 2001 From: Alyssa Ross Date: Mon, 6 Jul 2020 12:46:15 +0000 Subject: sys_util: make UnixSeqpacket::recv use libc::recv 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 --- 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 a2de0c4..341bbfa 100644 --- a/sys_util/src/net.rs +++ b/sys_util/src/net.rs @@ -198,7 +198,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. @@ -207,11 +207,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 { // 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 { -- cgit 1.4.1