From: Mat Martineau <martineau@kernel.org>
To: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Cc: MPTCP Upstream <mptcp@lists.linux.dev>
Subject: Re: [PATCH mptcp-net v2 1/2] mptcp: pm: avoid sending RM_ADDR over same subflow
Date: Tue, 24 Feb 2026 20:12:53 -0800 (PST) [thread overview]
Message-ID: <60bfc032-effc-f85f-6e64-7af0cd3daeeb@kernel.org> (raw)
In-Reply-To: <20260220-mptcp-issue-612-v2-1-089684a6edcb@kernel.org>
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.
>
> Fixes: 8dd5efb1f91b ("mptcp: send ack for rm_addr")
> Reported-by: Frank Lorenz
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/612
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> Note: in my initial version, I only used one alternative for both
> "stale" and "same id" subflows. I guess it is better to send over the
> same subflow than a stale one, hence the priority, but there are then a
> few more lines of code (but still readable, I think). To be discussed.
>
> v2:
> - reduce one indentation level and s/rlist/rm_list/g
> ---
> net/mptcp/pm.c | 55 +++++++++++++++++++++++++++++++++++++++++++------------
> 1 file changed, 43 insertions(+), 12 deletions(-)
>
> diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
> index 8206b0fd2377..daef91e597ae 100644
> --- a/net/mptcp/pm.c
> +++ b/net/mptcp/pm.c
> @@ -212,9 +212,24 @@ void mptcp_pm_send_ack(struct mptcp_sock *msk,
> spin_lock_bh(&msk->pm.lock);
> }
>
> -void mptcp_pm_addr_send_ack(struct mptcp_sock *msk)
> +static bool subflow_in_rm_list(const struct mptcp_subflow_context *subflow,
> + const struct mptcp_rm_list *rm_list)
> {
> - struct mptcp_subflow_context *subflow, *alt = NULL;
> + u8 i, id = subflow_get_local_id(subflow);
> +
> + for (i = 0; i < rm_list->nr; i++) {
> + if (rm_list->ids[i] == id)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void
> +mptcp_pm_addr_send_ack_avoid_list(struct mptcp_sock *msk,
> + const struct mptcp_rm_list *rm_list)
> +{
> + struct mptcp_subflow_context *subflow, *stale = NULL, *same_id = NULL;
>
> msk_owned_by_me(msk);
> lockdep_assert_held(&msk->pm.lock);
> @@ -224,19 +239,35 @@ void mptcp_pm_addr_send_ack(struct mptcp_sock *msk)
> return;
>
> mptcp_for_each_subflow(msk, subflow) {
> - if (__mptcp_subflow_active(subflow)) {
> - if (!subflow->stale) {
> - mptcp_pm_send_ack(msk, subflow, false, false);
> - return;
> - }
> + if (!__mptcp_subflow_active(subflow))
> + continue;
>
> - if (!alt)
> - alt = subflow;
> + if (unlikely(subflow->stale)) {
> + if (!stale)
> + stale = subflow;
> + } else if (unlikely(rm_list &&
> + subflow_in_rm_list(subflow, rm_list))) {
> + if (!same_id)
> + same_id = subflow;
> + } else {
> + goto send_ack;
Hi Matthieu -
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).
The v2 patch here is closer to the existing behavior so I'm ok with
approving it:
Reviewed-by: Mat Martineau <martineau@kernel.org>
> }
> }
>
> - if (alt)
> - mptcp_pm_send_ack(msk, alt, false, false);
> + if (same_id)
> + subflow = same_id;
> + else if (stale)
> + subflow = stale;
> + else
> + return;
> +
> +send_ack:
> + mptcp_pm_send_ack(msk, subflow, false, false);
> +}
> +
> +void mptcp_pm_addr_send_ack(struct mptcp_sock *msk)
> +{
> + mptcp_pm_addr_send_ack_avoid_list(msk, NULL);
> }
>
> int mptcp_pm_mp_prio_send_ack(struct mptcp_sock *msk,
> @@ -470,7 +501,7 @@ int mptcp_pm_remove_addr(struct mptcp_sock *msk, const struct mptcp_rm_list *rm_
> msk->pm.rm_list_tx = *rm_list;
> rm_addr |= BIT(MPTCP_RM_ADDR_SIGNAL);
> WRITE_ONCE(msk->pm.addr_signal, rm_addr);
> - mptcp_pm_addr_send_ack(msk);
> + mptcp_pm_addr_send_ack_avoid_list(msk, rm_list);
> return 0;
> }
>
>
> --
> 2.51.0
>
>
>
next prev parent reply other threads:[~2026-02-25 4:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 11:25 [PATCH mptcp-net v2 0/2] mptcp: pm: avoid sending RM_ADDR over the same subflow Matthieu Baerts (NGI0)
2026-02-20 11:25 ` [PATCH mptcp-net v2 1/2] mptcp: pm: avoid sending RM_ADDR over " Matthieu Baerts (NGI0)
2026-02-25 4:12 ` Mat Martineau [this message]
2026-02-25 12:18 ` Matthieu Baerts
2026-02-25 16:57 ` Mat Martineau
2026-02-26 7:39 ` Matthieu Baerts
2026-02-20 11:25 ` [PATCH mptcp-net v2 2/2] selftests: mptcp: join: check RM_ADDR not sent " Matthieu Baerts (NGI0)
2026-02-20 12:42 ` [PATCH mptcp-net v2 0/2] mptcp: pm: avoid sending RM_ADDR over the " MPTCP CI
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60bfc032-effc-f85f-6e64-7af0cd3daeeb@kernel.org \
--to=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox