Re: [PATCH bpf v5 2/2] selftests/bpf: allocate a larger timeout for connection

> diff --git a/tools/testing/selftests/bpf/network_helpers.c b/tools/testing/selftests/bpf/network_helpers.c
> index d311db786880..ed4aeee1555d 100644
> --- a/tools/testing/selftests/bpf/network_helpers.c
> +++ b/tools/testing/selftests/bpf/network_helpers.c

[ ... ]

> @@ -291,6 +293,12 @@ int client_socket(int family, int type,
>  	return -1;
>  }
>
> +static int connect_timeout_ms(const struct network_helper_opts *opts)
> +{
> +	/* Enforce a minimum connect timeout value */
> +	return MAX(opts->timeout_ms, CONNECT_MIN_TIMEOUT_MS);
> +}
> +
>  int connect_to_addr(int type, const struct sockaddr_storage *addr, socklen_t addrlen,
>  		    const struct network_helper_opts *opts)
>  {
> @@ -305,13 +313,35 @@ int connect_to_addr(int type, const struct sockaddr_storage *addr, socklen_t add
>  		return -1;
>  	}
>
> +	/*
> +	 * Override timeout configuration with a larger value for the
> +	 * connection
> +	 */
> +	if (settimeo(fd, connect_timeout_ms(opts))) {
> +		log_err("Failed to set connect timeout");
> +		goto close;
> +	}
> +
>  	if (connect(fd, (const struct sockaddr *)addr, addrlen)) {
> -		log_err("Failed to connect to server");
> -		save_errno_close(fd);
> -		return -1;
> +		log_err("Failed to connect");
> +		goto close;
> +	}
> +
> +	/*
> +	 * If the timeout configured by the test is different from the
> +	 * connect timeout, restore it
> +	 */
> +	if (opts->timeout_ms != CONNECT_MIN_TIMEOUT_MS &&
> +	    settimeo(fd, opts->timeout_ms)) {
> +		log_err("Failed to set timeout for connected socket");
> +		goto close;
                     ^^^^

Does this condition match what the comment describes? The value applied
to the socket before connect() is connect_timeout_ms(opts), which returns
MAX(opts->timeout_ms, CONNECT_MIN_TIMEOUT_MS). The guard tests
opts->timeout_ms != CONNECT_MIN_TIMEOUT_MS, so the two expressions only
match when opts->timeout_ms <= CONNECT_MIN_TIMEOUT_MS.

When a test passes a timeout larger than the minimum, the guard fires even
though the socket already has the right value. For example,
prog_tests/xdp_synproxy.c calls connect_to_fd(server_fd, 10000).
connect_timeout_ms() returns 10000, settimeo() applies 10000, then the guard
(10000 != 5000) is true and settimeo() re-applies the same 10000 value the
socket already has.

Would opts->timeout_ms != connect_timeout_ms(opts) express the stated
intent? That guard would be false when opts->timeout_ms == 10000 (nothing
to restore), and true when opts->timeout_ms < CONNECT_MIN_TIMEOUT_MS
(restore the smaller value the test asked for).

> +	}
> +
>  	return fd;
> +
> +close:
> +	save_errno_close(fd);
> +	return -1;
>  }


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31779510003