Re: CI failures on nipa

[gang.yan@linux.dev]

August 13, 2026 at 3:57 PM, "Paolo Abeni" <pabeni@redhat.com mailto:pabeni@redhat.com?to=%22Paolo%20Abeni%22%20%3Cpabeni%40redhat.com%3E > wrote:


> 
> Hi,
> 
> I'm looking at this one:
> 
> https://netdev-ctrl.bots.linux.dev/logs/vmksft/mptcp/results/776501/6-mptcp-connect-sh/
> 
> the output is strange:
> 
> https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/vmksft/mptcp/results/776501/6-mptcp-connect-sh/stdout#L114
> 
> the first nstat dump includes apparently the counters from all the
> previous runs, which is unexpected: the nstat_init/nstat_get/pr_nstat
> dance should allow showing the data from current run only right?
> 
> Also I think mptcp_lib_wait_timeout completes too late (after ~60 secs),
> when the listener already bailed out due to accept timeout (after ~30
> secs), so it does not show any info on the listener side. I fear it may
> also race with the actuall `timeout` command completion showing socket
> states after the user-space program completion.
> 
> Judging on the final status, I *think*/*guess* the (re)connect is
> hanged, possibly due to bad remote address?!? It could be useful to
> print out on stderr the reconnect destination address.

Hi Paolo,

That reminds me of an issue when I was reading mptcp_connect.c a long
time ago:

At the end of 'sock_connect_mptcp()', it calls 'freeaddrinfo(addr)',
the 'peer' pointer (which points into 'addr') remains. Later, the main loop
uses this peer pointer for reconnection attempts. If the memory has been freed
and reused, the address data could be overwritten, resulting in an invalid
remote address.

That might cause the hangs or failures you are seeing, right?

Thanks
Gang

> 
> /P
>