From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>
Cc: MPTCP Upstream <mptcp@lists.linux.dev>
Subject: Re: [PATCH mptcp-net v2 2/6] selftests: mptcp: join: rm: set backup flag
Date: Tue, 4 Nov 2025 09:47:48 +0100 [thread overview]
Message-ID: <ed7be7cc-5ff9-4a55-8d97-fa6be887b62d@kernel.org> (raw)
In-Reply-To: <0b8d61bc-836b-4f61-a8c7-a5ce17906e19@kernel.org>
On 04/11/2025 09:47, Matthieu Baerts wrote:
> On 04/11/2025 08:29, Geliang Tang wrote:
>> Hi Matt,
>>
>> On Tue, 2025-11-04 at 07:57 +0100, Matthieu Baerts wrote:
>>> Hi Geliang,
>>>
>>> Thank you for the review.
>>>
>>> 4 Nov 2025 07:06:34 Geliang Tang <geliang@kernel.org>:
>>>
>>>> Hi Matt,
>>>>
>>>> Thanks for this fix. It works indeed.
>>>>
>>>> On Sun, 2025-11-02 at 12:30 +0100, Matthieu Baerts (NGI0) wrote:
>>>>> Some of these 'remove' tests rarely fail because a subflow has
>>>>> been
>>>>
>>>> In my testing, only the "flush addresses" test case fails
>>>> intermittently. I'm wondering which other test cases have failed in
>>>> your environment?
>>>
>>> I took the unstable ones from the Netdev and MPTCP CIs:
>>>
>>> https://netdev.bots.linux.dev/contest.html?pass=0&executor=vmksft-mptcp-dbg&ld-cases=1
>>>
>>> https://ci-results.mptcp.dev/flakes.html
>>>
>>>> I'm thinking we shouldn't add the "backup" flag to every test in
>>>> remove_tests, but only to the specific ones that are actually
>>>> failing.
>>>>
>>>> Similarly for patches 3 and 4, we don't need to add
>>>> "test_linkfail=128"
>>>> to every test. We should only apply it to the specific ones that
>>>> are
>>>> actually failing.
>>>
>>> If my analysis is correct, it means the simple fixes I did (backup
>>> and
>>> longer file size) can be applied to multiple tests. Then probably
>>> better
>>> to avoid these other tests to fail for the same reasons even if it is
>>> very
>>> rare, and very hard to reproduce, no? Each false positive takes a lot
>>> of
>>> resources (mainly time) to debug.
>>
>> I'll leave it to you to decide. However, I still believe it's better to
>> apply these fixes to the tests one by one, in case we see failures in
>> the future.
>
> Because these modifications are not modifying what is being validated in
> the test, but only avoid noises that would make the tests failing, I
> think it is better to prevent issues and waiting for them to happen.
I meant to say: "it is better to prevent issues *than* waiting for them
to happen.".
>
>> I'll respond with my Reviewed-by tag in the cover letter.
>
> Thanks!
>
> Cheers,
> Matt
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
next prev parent reply other threads:[~2025-11-04 8:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-02 11:30 [PATCH mptcp-net v2 0/6] selftests: mptcp: join: fix flaky tests Matthieu Baerts (NGI0)
2025-11-02 11:30 ` [PATCH mptcp-net v2 1/6] selftests: mptcp: connect: fix fallback note due to OoO Matthieu Baerts (NGI0)
2025-11-04 5:53 ` Geliang Tang
2025-11-02 11:30 ` [PATCH mptcp-net v2 2/6] selftests: mptcp: join: rm: set backup flag Matthieu Baerts (NGI0)
2025-11-04 6:06 ` Geliang Tang
2025-11-04 6:57 ` Matthieu Baerts
2025-11-04 7:29 ` Geliang Tang
2025-11-04 8:47 ` Matthieu Baerts
2025-11-04 8:47 ` Matthieu Baerts [this message]
2025-11-02 11:30 ` [PATCH mptcp-net v2 3/6] selftests: mptcp: join: endpoints: longer transfer Matthieu Baerts (NGI0)
2025-11-02 11:30 ` [PATCH mptcp-net v2 4/6] selftests: mptcp: join: userspace: " Matthieu Baerts (NGI0)
2025-11-02 11:30 ` [PATCH mptcp-net v2 5/6] selftests: mptcp: join: fastclose: drop plain RST Matthieu Baerts (NGI0)
2025-11-03 7:16 ` Geliang Tang
2025-11-02 11:30 ` [PATCH mptcp-net v2 6/6] selftests: mptcp: connect: trunc: read all recv data Matthieu Baerts (NGI0)
2025-11-03 7:13 ` Geliang Tang
2025-11-03 12:12 ` Matthieu Baerts
2025-11-04 5:56 ` Geliang Tang
2025-11-02 12:33 ` [PATCH mptcp-net v2 0/6] selftests: mptcp: join: fix flaky tests MPTCP CI
2025-11-03 11:57 ` MPTCP CI
2025-11-04 7:30 ` Geliang Tang
2025-11-04 12:10 ` Matthieu Baerts
2025-11-05 2:00 ` Geliang Tang
2025-11-05 5:57 ` Geliang Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed7be7cc-5ff9-4a55-8d97-fa6be887b62d@kernel.org \
--to=matttbe@kernel.org \
--cc=geliang@kernel.org \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.