On Thu, 30 Jun 2022, Geliang Tang wrote:

> On Thu, Jun 30, 2022 at 10:32:37AM +0000, MPTCP CI wrote:
>> Hi Geliang,
>>
>> Thank you for your modifications, that's great!
>>
>> Our CI did some validations and here is its report:
>>
>> - KVM Validation: normal:
>>   - Unstable: 1 failed test(s): selftest_simult_flows - Critical: 2 Call Trace(s) ❌:
>>   - Task: https://cirrus-ci.com/task/5934869556494336
>>   - Summary: https://api.cirrus-ci.com/v1/artifact/task/5934869556494336/summary/summary.txt
>>
>> - KVM Validation: debug:
>>   - Unstable: 1 failed test(s): selftest_mptcp_join - Critical: 2 Call Trace(s) ❌:
>>   - Task: https://cirrus-ci.com/task/5371919603073024
>>   - Summary: https://api.cirrus-ci.com/v1/artifact/task/5371919603073024/summary/summary.txt
>>
>> Initiator: Patchew Applier
>> Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/012eddf81089
>>
>>
>> If there are some issues, you can reproduce them using the same environment as
>> the one used by the CI thanks to a docker image, e.g.:
>>
>>     $ cd [kernel source code]
>>     $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
>>         --pull always mptcp/mptcp-upstream-virtme-docker:latest \
>>         auto-debug
>>
>> For more details:
>>
>>     https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
>>
>>
>> Please note that despite all the efforts that have been already done to have a
>> stable tests suite when executed on a public CI like here, it is possible some
>> reported issues are not due to your modifications. Still, do not hesitate to
>> help us improve that ;-)
>>
>> Cheers,
>> MPTCP GH Action bot
>> Bot operated by Matthieu Baerts (Tessares)
>
> Hi Matt,
>
> I can't reproduce all the CI failures. All tests (mptcp_connect.sh,
> mptcp_join.sh and bpf mptcp selftests) passed on my side.
>
> All the test logs are attached.

I checked out the tag that the CI built from 
(patchew/cover.1656578856.git.geliang.tang@suse.com), and it looks like 
the CI hit this:

if (WARN_ON_ONCE(!msk->recovery))

at line 999 of protocol.c, so this is an unexpected instance where dfrag 
== msk->first_pending and msk->recovery is not set. My guess is that 
msk->first_pending is not getting updated before returning from 
__mptcp_push_pending() in some rare case. I'll look for this when 
reviewing patch 2.



--
Mat Martineau
Intel