Re: [PATCH v5 mptcp-next 00/10] mptcp: introduce backlog processing

[Paolo Abeni <pabeni@redhat.com>]

On 10/13/25 11:07 AM, Geliang Tang wrote:
> On Fri, 2025-10-10 at 20:22 +0800, Geliang Tang wrote:
>> Hi Paolo,
>>
>> On Fri, 2025-10-10 at 10:21 +0200, Paolo Abeni wrote:
>>> On 10/9/25 3:58 PM, Paolo Abeni wrote:
>>>> @Geliang: if you reproduce the issue multiple times, are there
>>>> any
>>>> common patterns ? i.e. sender files considerably larger than the
>>>> client
>>>> one, or only a specific subsets of all the test-cases failing, or
>>>> ...
>>>
>>> Other questions:
>>> - Can you please share your setup details (VM vs baremetal, debug
>>> config
>>> vs non debug, vmg vs plain qemu, number of [v]cores...)? I can't
>>> repro
>>> the issue locally.
>>
>> Here are my modifications:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/geliang/mptcp_net-next.git/log/?h=splice_new
>>
>> I used mptcp-upstream-virtme-docker normal config to reproduce it:
>>
>> docker run \
>> 	-e INPUT_NO_BLOCK=1 \
>> 	-e INPUT_PACKETDRILL_NO_SYNC=1 \
>> 	-v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
>>         --pull always ghcr.io/multipath-tcp/mptcp-upstream-virtme-
>> docker:latest \
>> 	auto-normal
>>
>> $ cat .virtme-exec-run 
>> run_loop run_selftest_one ./mptcp_connect_splice.sh
>>
>> Running mptcp_connect_splice.sh in a loop dozens of times should
>> reproduce the test failure.
>>
>>> - Can you please share a pcap capture _and_ the selftest text
>>> output
>>> for
>>> the same failing  test?
> 
> The pcap captures (gQQ13x-ns1-ns3-MPTCP-MPTCP-dead:beef:3::2-10013-
> connector.pcap, gQQ13x-ns1-ns3-MPTCP-MPTCP-dead:beef:3::2-10013-
> listener.pcap) and the selftest text output (selftest_output) are
> attached.

Looks like the 'stuck' scenario is quite consistent. The receiver filled
it's receive window, and sent an ack shortly after when re-opening, but
the sender did not react to such ack.

The perf instrumentation I mentioned would be very useful. I tried to
capture it myself, but so far I failed - the repro run for several
hundred iterations without issues and finally podmad stuck (podman bug
apparently, or local resources exhausted).

Did you have better luck collecting the perf trace?

/P