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

[Matthieu Baerts <matttbe@kernel.org>]

Hi Gang,

On 05/11/2025 03:13, GangYan wrote:
>> 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.

OK, so the WARN_ON_ONCE() is not shown because add_addr_accepted is
never decremented, but it should have been decremented (not below the
limit).

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

I think you can use 'ss', because it is already used in this test, see
chk_mptcp_info().

I suggest applying the fix now, the test can be added later.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.