Re: [PATCH bpf v3 1/2] selftests/bpf: keep polling connection that is still in progress

[Alexis Lothoré]

On Tue Aug 11, 2026 at 5:05 PM CEST, Jiayuan Chen wrote:
>
> On 8/11/26 10:26 PM, Alexis Lothoré (eBPF Foundation) wrote:
>> Some tests, like tc_tunnel or tc_edt, sporadically fail in CI with the
>> following logs:
>>
>>    (network_helpers.c:309: errno: Operation now in progress) \
>>      Failed to connect to server
>>    send_and_test_data:FAIL:connect to server unexpected error: -115
>>
>> This is due to SO_RCVTIMEO and SO_SNDTIMEO being set on the client
>> socket (see settimeo() in client_socket()), allowing connect() to return
>> an error and to set errno to EINPROGRESS instead of blocking until
>> connection result is known. Increasing the timeout value for those tests
>> is likely not a good solution (and it has already been done by commit
>> 2790db208b44 ("selftests/bpf: Improve tc_tunnel test reliability")):
>> they involve subtests that expect the connection to fail, and so
>> increasing the timeout value would increase overall test execution
>> duration again (not only the connection, but any socket operation).
>>
>> Another solution, as documented in man 2 connect, is to poll the socket
>> for POLLOUT once connect has returned EINPROGRESS, and to get the actual
>> connection result through getsockopt: this allows to keep the overall
>> timeout values low for the general traffic, while letting a chance to
>> the connection to succeed even if CI runners are loaded.
>>
>> When connect() returns EINPROGRESS, poll the socket for POLLOUT and
>> check the connection result via getsockopt(SO_ERROR). This new handling
>> conforms to the configured timeout: the polling loop will only run for
>> the amount of time still available, accounting for the time used by the
>> initial connect() call.
>
>
> So IIUC this patch doesn't actually fix the flakiness: connect() on a 
> blocking socket only
> returns EINPROGRESS after SO_SNDTIMEO is fully consumed, so remaining_ms 
> is always ~0 and the
> overall time budget is still 1s, same as before. Am I missing something?

Hmmm, I have been assuming that this EINPROGRESS could be returned
_before_ the configured timeout depletion, but I may have been mistaken,
it indeed happens only  the socket is O_NONBLOCK, which is not the case
here. So indeed, it does not fix anything for the blocking case, as the
budget is already depleted when getting EINPROGRESS...

I added this budget mechanism to follow up on Ihor's suggestion, so I
either got it wrong, or it can not work. An intermediate solution could
be to exceptionally raise the budget by 1s when getting EINPROGRESS.
That potentially brings back part of the issues he has been mentioning
with selftests duration possibly increasing by a non negligeable amount,
but maybe 1s is a better compromise, compared to my initial 3s proposal
?

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com