From: sashiko-bot@kernel.org
To: "Akshit Patadiya" <akshit@mpiricsoftware.com>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next] mptcp: fix add_addr_accepted accounting on subflow close
Date: Thu, 13 Aug 2026 12:53:58 +0000 [thread overview]
Message-ID: <20260813125358.CBCD51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813123754.4095492-1-akshit@mpiricsoftware.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Concurrent overwrite of msk->pm.rm_list_rx while iterating over it in mptcp_pm_rm_addr_or_subflow.
--
--- Patch [1]: [PATCH mptcp-next] mptcp: fix add_addr_accepted accounting on subflow close ---
commit 66a438e0ebd8ec5a7b6eb2a506d61f6a2a2d2cc5
Author: Akshit Patadiya <akshit@mpiricsoftware.com>
mptcp: fix add_addr_accepted accounting on subflow close
This commit modifies how MPTCP tracks accepted remote addresses by using a
bitmap instead of relying on a live subflow to signal removal. It releases
accepted-address slots as soon as the subflow is closed.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/498
> diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
> index ba7c6f80a183c..b6edb9df3216c 100644
> --- a/net/mptcp/pm.c
> +++ b/net/mptcp/pm.c
[ ... ]
> @@ -807,7 +808,6 @@ static void mptcp_pm_rm_addr_or_subflow(struct mptcp_sock *msk,
> i, rm_id, id, remote_id, msk->mpc_endpoint_id);
> spin_unlock_bh(&msk->pm.lock);
> mptcp_subflow_shutdown(sk, ssk, how);
> - removed |= subflow->request_join;
>
> /* the following takes care of updating the subflows counter */
> mptcp_close_ssk(sk, ssk, subflow);
[Severity: High]
This isn't a bug introduced by this patch, but could this unlock/lock sequence
lead to a race condition with the outer loop?
In mptcp_pm_rm_addr_or_subflow(), the outer loop iterates over rm_list:
for (i = 0; i < rm_list->nr; i++) {
u8 rm_id = rm_list->ids[i];
If rm_list points to &msk->pm.rm_list_rx, and the PM lock is dropped here
in the inner loop, could a concurrent softirq processing a new RM_ADDR
overwrite the list while the lock is temporarily released?
This might corrupt the ongoing iteration of the outer loop once the lock is
reacquired and the next item in rm_list->nr and rm_list->ids is evaluated.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813123754.4095492-1-akshit@mpiricsoftware.com?part=1
next prev parent reply other threads:[~2026-08-13 12:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 12:37 [PATCH mptcp-next] mptcp: fix add_addr_accepted accounting on subflow close Akshit Patadiya
2026-08-13 12:53 ` sashiko-bot [this message]
2026-08-13 13:52 ` MPTCP CI
2026-09-03 9:06 ` Akshit Patadiya
-- strict thread matches above, loose matches on Subject: below --
2026-08-13 11:32 Akshit Patadiya
2026-08-13 11:49 ` sashiko-bot
2026-08-13 12:56 ` 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=20260813125358.CBCD51F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akshit@mpiricsoftware.com \
--cc=mptcp@lists.linux.dev \
--cc=sashiko-reviews@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