-
Notifications
You must be signed in to change notification settings - Fork 682
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple failures in test_vsock #1934
Comments
That test has inconsistent behavior on different platforms. See nix-rust#1934 .
That test has inconsistent behavior on different platforms. See nix-rust#1934 .
@asomers yep, I'll fix the test, making it more reliable. About This will make the test to fail, since now it is able to handle loopback. I think we should avoid trying the connection, since it can change depending on where the test is running. Something like this: diff --git a/test/sys/test_socket.rs b/test/sys/test_socket.rs
index 2ab6c54..d3fbbaa 100644
--- a/test/sys/test_socket.rs
+++ b/test/sys/test_socket.rs
@@ -2080,10 +2080,9 @@ pub fn test_vsock() {
)
.expect("socket failed");
- let sockaddr_host = VsockAddr::new(cid, port);
+ let sockaddr_host = VsockAddr::new(cid, port + 1);
- // The current implementation does not support loopback devices, so,
- // for now, we expect a failure on the connect.
+ // We expect a failure on the connect since we are using a wrong port.
assert_ne!(connect(s2, &sockaddr_host), Ok(()));
close(s2).unwrap(); I'll send a PR ASAP. |
I agree, I'll remove that part.
Okay, I'll send it! |
We mainly provide VsockAddr, so let's try to test well that VsockAddr mapping to libc::sockaddr_vm is correct. Let's remove all interactions with the socket, since vsock may or may not be available in the environment. Testing socket(), bind(), listen(), connect(), etc. caused unexpected failures, and it's out of scope of this crate. So let's simplify the vsock test focussing on VsockAddr. This should work also on graviton, so let's try to re-enable it. Fixes nix-rust#1934 Signed-off-by: Stefano Garzarella <[email protected]>
1944: Rework vsock test r=asomers a=stefano-garzarella We mainly provide VsockAddr, so let's try to test well that VsockAddr mapping to libc::sockaddr_vm is correct. Let's remove all interactions with the socket, since vsock may or may not be available in the environment. Testing socket(), bind(), listen(), connect(), etc. caused unexpected failures, and it's out of scope of this crate. So let's simplify the vsock test focussing on VsockAddr. This should work also on graviton, so let's try to re-enable it. Fixes #1934 Signed-off-by: Stefano Garzarella <[email protected]> Co-authored-by: Stefano Garzarella <[email protected]>
We mainly provide VsockAddr, so let's try to test well that VsockAddr mapping to libc::sockaddr_vm is correct. Let's remove all interactions with the socket, since vsock may or may not be available in the environment. Testing socket(), bind(), listen(), connect(), etc. caused unexpected failures, and it's out of scope of this crate. So let's simplify the vsock test focussing on VsockAddr. This should work also on graviton, so let's try to re-enable it. Fixes nix-rust#1934 Signed-off-by: Stefano Garzarella <[email protected]>
We mainly provide VsockAddr, so let's try to test well that VsockAddr mapping to libc::sockaddr_vm is correct. Let's remove all interactions with the socket, since vsock may or may not be available in the environment. Testing socket(), bind(), listen(), connect(), etc. caused unexpected failures, and it's out of scope of this crate. So let's simplify the vsock test focussing on VsockAddr. This should work also on graviton, so let's try to re-enable it. Fixes nix-rust#1934 Signed-off-by: Stefano Garzarella <[email protected]>
When we first added the vsock code in #1091 the test contained an assertion that connecting to the socket would fail, because "The current implementation does not support loopback devices". But it did not check the particular failure mode. A recent change (#1915) has caused
connect
to start succeeding, in at least some cases. It seems that at least some of the original failures were due to a race condition in the test: it closed a socket too early. Now that that is fixed, we see three behaviors:See #1917 to view the behavior on each platform.
@stefano-garzarella could you please clarify what we should expect from
connect
, and fix the test? For now I'm going to disable it so it doesn't hold up other PRs.The text was updated successfully, but these errors were encountered: