linux/tools/testing/vsock, branch v6.16

vsock/test: Add test for an unexpectedly lingering close()

2025-05-27T09:05:22Z

There was an issue with SO_LINGER: instead of blocking until all queued messages for the socket have been successfully sent (or the linger timeout has been reached), close() would block until packets were handled by the peer. Add a test to alert on close() lingering when it should not. Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250522-vsock-linger-v6-5-2ad00b0e447e@rbox.co Signed-off-by: Paolo Abeni

vsock/test: Introduce enable_so_linger() helper

2025-05-27T09:05:21Z

Add a helper function that sets SO_LINGER. Adapt the caller. Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250522-vsock-linger-v6-4-2ad00b0e447e@rbox.co Signed-off-by: Paolo Abeni

vsock/test: Introduce vsock_wait_sent() helper

2025-05-27T09:05:21Z

Distill the virtio_vsock_sock::bytes_unsent checking loop (ioctl SIOCOUTQ) and move it to utils. Tweak the comment. Signed-off-by: Michal Luczaj Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20250522-vsock-linger-v6-3-2ad00b0e447e@rbox.co Signed-off-by: Paolo Abeni

vsock/test: check also expected errno on sigpipe test

2025-05-17T01:01:32Z

In the sigpipe test, we expect send() to fail, but we do not check if send() fails with the errno we expect (EPIPE). Add this check and repeat the send() in case of EINTR as we do in other tests. Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20250514141927.159456-4-sgarzare@redhat.com Signed-off-by: Jakub Kicinski

vsock/test: retry send() to avoid occasional failure in sigpipe test

2025-05-17T01:01:32Z

When the other peer calls shutdown(SHUT_RD), there is a chance that the send() call could occur before the message carrying the close information arrives over the transport. In such cases, the send() might still succeed. To avoid this race, let's retry the send() call a few times, ensuring the test is more reliable. Sleep a little before trying again to avoid flooding the other peer and filling its receive buffer, causing false-negative. Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20250514141927.159456-3-sgarzare@redhat.com Signed-off-by: Jakub Kicinski

vsock/test: add timeout_usleep() to allow sleeping in timeout sections

2025-05-17T01:01:32Z

The timeout API uses signals, so we have documented not to use sleep(), but we can use nanosleep(2) since POSIX.1 explicitly specifies that it does not interact with signals. Let's provide timeout_usleep() for that. Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20250514141927.159456-2-sgarzare@redhat.com Signed-off-by: Jakub Kicinski

vsock/test: Fix occasional failure in SIOCOUTQ tests

2025-05-13T22:01:50Z

These tests: "SOCK_STREAM ioctl(SIOCOUTQ) 0 unsent bytes" "SOCK_SEQPACKET ioctl(SIOCOUTQ) 0 unsent bytes" output: "Unexpected 'SIOCOUTQ' value, expected 0, got 64 (CLIENT)". They test that the SIOCOUTQ ioctl reports 0 unsent bytes after the data have been received by the other side. However, sometimes there is a delay in updating this "unsent bytes" counter, and the test fails even though the counter properly goes to 0 several milliseconds later. The delay occurs in the kernel because the used buffer notification callback virtio_vsock_tx_done(), called upon receipt of the data by the other side, doesn't update the counter itself. It delegates that to a kernel thread (via vsock->tx_work). Sometimes that thread is delayed more than the test expects. Change the test to poll SIOCOUTQ until it returns 0 or a timeout occurs. Signed-off-by: Konstantin Shkolnyy Reviewed-by: Stefano Garzarella Fixes: 18ee44ce97c1 ("test/vsock: add ioctl unsent bytes test") Link: https://patch.msgid.link/20250507151456.2577061-1-kshk@linux.ibm.com Signed-off-by: Jakub Kicinski

vsock/test: Add test for SO_LINGER null ptr deref

2025-02-13T04:01:29Z

Explicitly close() a TCP_ESTABLISHED (connectible) socket with SO_LINGER enabled. As for now, test does not verify if close() actually lingers. On an unpatched machine, may trigger a null pointer dereference. Tested-by: Luigi Leonardi Reviewed-by: Luigi Leonardi Reviewed-by: Stefano Garzarella Signed-off-by: Michal Luczaj Link: https://patch.msgid.link/20250210-vsock-linger-nullderef-v3-2-ef6244d02b54@rbox.co Signed-off-by: Jakub Kicinski

vsock/test: Add test for connect() retries

2025-01-30T02:50:37Z

Deliberately fail a connect() attempt; expect error. Then verify that subsequent attempt (using the same socket) can still succeed, rather than fail outright. Reviewed-by: Stefano Garzarella Reviewed-by: Luigi Leonardi Signed-off-by: Michal Luczaj Link: https://patch.msgid.link/20250128-vsock-transport-vs-autobind-v3-6-1cf57065b770@rbox.co Signed-off-by: Jakub Kicinski

vsock/test: Add test for UAF due to socket unbinding

2025-01-30T02:50:37Z

Fail the autobind, then trigger a transport reassign. Socket might get unbound from unbound_sockets, which then leads to a reference count underflow. Reviewed-by: Stefano Garzarella Signed-off-by: Michal Luczaj Link: https://patch.msgid.link/20250128-vsock-transport-vs-autobind-v3-5-1cf57065b770@rbox.co Signed-off-by: Jakub Kicinski