Re: [PATCH bpf v3 1/2] selftests/bpf: keep polling connection that is still in progress
Ihor Solodrai <[email protected]>
| Newsgroups | org.kernel.vger.linux-kselftest,org.kernel.vger.bpf,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 2026-08-13 12:29 a.m., Alexis Lothoré wrote:
> Hi Ihor,
> thanks for the extensive investigation
>
> On Wed Aug 12, 2026 at 8:46 PM CEST, Ihor Solodrai wrote:
>> On 8/11/26 9:25 AM, Alexis Lothoré wrote:
>>> 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:
>
> [...]
>
>
>> An entirely different alternative that Eduard brought up in an
>> off-list discussion, is to drop all the timeout machinery from
>> network_helpers.c altogether, and rely solely on the test_progs
>> watchdog to kill the subtest processes: d9d4d127e813 ("selftests/bpf:
>> watchdog timer for test_progs")
>>
>> I am not convinced it's a good idea, because I don't know what will
>> happen with all the tc_* tests if there is no connection timeouts. If
>> you're interested, you could try it and see.
>
> Hmmm, I'm not very familiar with this mechanism, but aside from the
> potential issues you are mentioning, wouldn't it make us loose a bit of
> info here, when the watchdog kicks the runner out ? We may know from the
> stacktrace that the subtest was in connect(), but we would loose any
> formal error/errno on connection timeout I guess, and I am not sure how
> confident we can get about any watchdog kick being a connect timeout.
That's a good point. The watchdog is the killer of last resort,
we should report proper errors whenever possible, I agree.
>
>>> 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
>>> ?
>>>
>
>
>
>