On 5/8/25 4:20 PM, Stefano Garzarella wrote:
> From: Stefano Garzarella <sgarz...@redhat.com>
>
> 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.
>
> Signed-off-by: Stefano Garzarella <sgarz...@redhat.com>
> ---
> tools/testing/vsock/vsock_test.c | 28 ++++++++++++++++++----------
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/tools/testing/vsock/vsock_test.c
> b/tools/testing/vsock/vsock_test.c
> index d0f6d253ac72..7de870dee1cf 100644
> --- a/tools/testing/vsock/vsock_test.c
> +++ b/tools/testing/vsock/vsock_test.c
> @@ -1064,11 +1064,18 @@ static void test_stream_check_sigpipe(int fd)
>
> have_sigpipe = 0;
>
> - res = send(fd, "A", 1, 0);
> - if (res != -1) {
> - fprintf(stderr, "expected send(2) failure, got %zi\n", res);
> - exit(EXIT_FAILURE);
> - }
> + /* 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.
> + */
> + timeout_begin(TIMEOUT);
> + do {
> + res = send(fd, "A", 1, 0);
> + timeout_check("send");
> + } while (res != -1);
AFAICS the above could spin on send() for up to 10s, I would say
considerably more than 'a few times' ;)
In practice that could cause side effect on the timing of other
concurrent tests (due to one CPU being 100% used for a while).
What if the peer rcvbuf fills-up: will the send fail? That could cause
false-negative.
I *think* it should be better to insert a short sleep in the loop.
/P
