Re: [PATCH, mptcp-net] mptcp: fix address removal logic in mptcp_pm_nl_rm_addr

[GangYan <gang.yan@linux.dev>]

> On Tue, Nov 04, 2025 at 03:34:38PM +0100, Matthieu Baerts wrote:
> Hi Gang,
> 
> On 04/11/2025 13:34, Gang Yan wrote:
> > From: Gang Yan <yangang@kylinos.cn>
> > 
> > Fix inverted WARN_ON_ONCE condition that prevented normal address
> > removal counter updates. The current code only executes decrement
> > logic when the counter is already 0 (abnormal state), while
> > normal removals (counter > 0) are ignored.
> 
> Good catch!
> 
> For fixes, we need a Fixes tag:
> 
> Fixes: 636113918508 ("mptcp: pm: remove '_nl' from
> mptcp_pm_nl_rm_addr_received")
> 
> Apart from that, it looks good to me:
> 
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> 
> How did you find out about this? I'm surprised out test suite didn't
> spot it. By chance, do you have a test that can be used to reproduce
> this issue?

I've been looking into the work_pending-related issue described in
#ISSUE 440 and have designed several potentially affected scenarios
based on mptcp_join tests. Except for the case where endpoints are
deleted one by one and then re-added via ADD_ADDR (which fails), all
other related tests have passed. (I'll share some conclusions in the
corresponding discussion later.)

By tracing the relevant code, I found that the value of
'add_addr_accepted' here does not decrease, which subsequently blocks
further ADD_ADDR operations. We can verify the value of
'add_addr_accepted' in 'delete re-add signal' test, which can be found
in mptcp_join.sh, using either 'ss' or 'mptcp_diag'. The reason this
test didn't fail previously is that when the 'add_addr_accepted_limit'
was set to 3, the test's add_addr operations never reached the limit,
so no overflow occurred.

I lean toward using 'ss' to obtain the token and then retrieving the
'add_addr_accepted' value via 'mptcp_diag', because when the value is
zero, ss does not display it. Moreover, using 'mptcp_diag' minimizes
potential inconsistencies caused by different versions of iproute2,
making maintenance easier. WDYT?

Thanks,
Gang
> 
> Cheers,
> Matt
> -- 
> Sponsored by the NGI0 Core fund.
>