On Fri, 1 Jul 2022, Mat Martineau wrote:

> 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.

I think this will probably be fixed by changing the dfrag updates as I 
describe in the patch 2 review comments.

--
Mat Martineau
Intel