> 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
