Re: [PATCH mptcp-net v2 1/2] mptcp: pm: avoid sending RM_ADDR over same subflow

[Mat Martineau <martineau@kernel.org>]

On Wed, 25 Feb 2026, Matthieu Baerts wrote:

> Hi Mat,
>
> Thank you for the review!
>
> On 25/02/2026 05:12, Mat Martineau wrote:
>> On Fri, 20 Feb 2026, Matthieu Baerts (NGI0) wrote:
>>
>>> RM_ADDR are sent over an active subflow, the first one in the subflows
>>> list. There is then a high chance the initial subflow is picked. With
>>> the in-kernel PM, when an endpoint is removed, a RM_ADDR is sent, then
>>> linked subflows are closed. This is done for each active MPTCP
>>> connection.
>>>
>>> MPTCP endpoints are likely removed because the attached network is no
>>> longer available or usable. In this case, it is better to avoid sending
>>> this RM_ADDR over the subflow that is going to be removed, but prefer
>>> sending it over another active and non stale subflow, if any.
>>>
>>> This modification avoids situations where the other end is not notified
>>> when a subflow is no longer usable: typically when the endpoint linked
>>> to the initial subflow is removed, especially on the server side.
>
> (...)
>
>> This is definitely an improvement over the older code, thanks! It does
>> still send RM_ADDR exactly once. It could also RM_ADDR using *all*
>> active non-stale subflows (any that are delivered after the first would
>> be ignored). In terms of interoperability there is the risk of confusing
>> the peer's path manager if it doesn't handle RM_ADDR for a non-existant
>> subflow.
>>
>> Maybe that's more of a mptcp-next feature (if it makes sense to do at all).
>
> I think implementing this would definitively be mptcp-next material. If
> we want this, we will also need to change the way the option is added:
> for the moment, the rm_list is copied in the msk, and a bit is set
> before triggering the ACK, and when sending the ACK, the bit is reset.
> So we would need to also record the subflow IDs that should send the
> RM_ADDR, and only remove the main bit when all of subflows have sent it.
>
> Now regarding the behaviour, I think it more likely to have concurrent
> issues: maybe a subflow could be re-created or an ADD_ADDR could be
> received before all RM_ADDR are transmitted, e.g. in case of bufferbloat
> on one path?
>
>> The v2 patch here is closer to the existing behavior so I'm ok with
>> approving it:
>>
>> Reviewed-by: Mat Martineau <martineau@kernel.org>
>
> Thanks! Is this tag also covering patch 2/2?
>

Yes, I had intended to reply to the cover letter to RvB the series. 
Thanks for clarifying.

- Mat