diff mbox series

[net-next,03/10] mptcp: userspace pm send RM_ADDR for ID 0

Message ID 20231025-send-net-next-20231025-v1-3-db8f25f798eb@kernel.org (mailing list archive)
State Mainlined, archived
Delegated to: Mat Martineau
Headers show
Series mptcp: Fixes and cleanup for v6.7 | expand

Commit Message

Mat Martineau Oct. 25, 2023, 11:37 p.m. UTC 
From: Geliang Tang <geliang.tang@suse.com>

This patch adds the ability to send RM_ADDR for local ID 0. Check
whether id 0 address is removed, if not, put id 0 into a removing
list, pass it to mptcp_pm_remove_addr() to remove id 0 address.

There is no reason not to allow the userspace to remove the initial
address (ID 0). This special case was not taken into account not
letting the userspace to delete all addresses as announced.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/379
Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
Cc: stable@vger.kernel.org
Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
---
 net/mptcp/pm_userspace.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

Comments

Jakub Kicinski Oct. 27, 2023, 3:26 a.m. UTC | #1 
On Wed, 25 Oct 2023 16:37:04 -0700 Mat Martineau wrote:
> Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
> Cc: stable@vger.kernel.org

CC: stable@ + net-next really doesn't make sense.
Either it's important or it's not. Which one do you pick?
Geliang Tang Oct. 27, 2023, 7:05 a.m. UTC | #2 
Hi Mat,

On Thu, Oct 26, 2023 at 08:26:29PM -0700, Jakub Kicinski wrote:
> On Wed, 25 Oct 2023 16:37:04 -0700 Mat Martineau wrote:
> > Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
> > Cc: stable@vger.kernel.org
> 
> CC: stable@ + net-next really doesn't make sense.
> Either it's important or it's not. Which one do you pick?

'Cc: stable@' in the first two patches should be dropped too.

Thanks,
-Geliang
Mat Martineau Oct. 27, 2023, 3:34 p.m. UTC | #3 
On Thu, 26 Oct 2023, Jakub Kicinski wrote:

> On Wed, 25 Oct 2023 16:37:04 -0700 Mat Martineau wrote:
>> Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
>> Cc: stable@vger.kernel.org
>
> CC: stable@ + net-next really doesn't make sense.
> Either it's important or it's not. Which one do you pick?
>

Hi Jakub -

This is what I was attempting to explain in the cover letter:

> This series includes three initial patches that we had queued in our 
> mptcp-net branch, but given the likely timing of net/net-next syncs this 
> week, the need to avoid introducing branch conflicts, and another batch 
> of net-next patches pending in the mptcp tree, the most practical route 
> is to send everything for net-next.

So, that's the reasoning, but I'll send v2 without the cc's.


- Mat
Jakub Kicinski Oct. 27, 2023, 3:43 p.m. UTC | #4 
On Fri, 27 Oct 2023 08:34:27 -0700 (PDT) Mat Martineau wrote:
> > This series includes three initial patches that we had queued in our 
> > mptcp-net branch, but given the likely timing of net/net-next syncs this 
> > week, the need to avoid introducing branch conflicts, and another batch 
> > of net-next patches pending in the mptcp tree, the most practical route 
> > is to send everything for net-next.  
> 
> So, that's the reasoning, but I'll send v2 without the cc's.

No need, I can strip when applying.
Mat Martineau Oct. 27, 2023, 3:45 p.m. UTC | #5 
On Fri, 27 Oct 2023, Jakub Kicinski wrote:

> On Fri, 27 Oct 2023 08:34:27 -0700 (PDT) Mat Martineau wrote:
>>> This series includes three initial patches that we had queued in our
>>> mptcp-net branch, but given the likely timing of net/net-next syncs this
>>> week, the need to avoid introducing branch conflicts, and another batch
>>> of net-next patches pending in the mptcp tree, the most practical route
>>> is to send everything for net-next.
>>
>> So, that's the reasoning, but I'll send v2 without the cc's.
>
> No need, I can strip when applying.
>

Thanks Jakub, appreciate this!


- Mat
Jakub Kicinski Oct. 27, 2023, 3:53 p.m. UTC | #6 
On Fri, 27 Oct 2023 08:45:53 -0700 (PDT) Mat Martineau wrote:
> > No need, I can strip when applying.
> 
> Thanks Jakub, appreciate this!

What's the reset of the stuff you have for 6.7, tho?
The net-next PR comes out today, unless it's really trivial cleanups
and/or selftest changes it's probably already too late :(
Assuming MW doesn't get postponed.
diff mbox series

Patch

diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
index 0f92e5b13a8a..25fa37ac3620 100644
--- a/net/mptcp/pm_userspace.c
+++ b/net/mptcp/pm_userspace.c
@@ -208,6 +208,40 @@  int mptcp_pm_nl_announce_doit(struct sk_buff *skb, struct genl_info *info)
 	return err;
 }
 
+static int mptcp_userspace_pm_remove_id_zero_address(struct mptcp_sock *msk,
+						     struct genl_info *info)
+{
+	struct mptcp_rm_list list = { .nr = 0 };
+	struct mptcp_subflow_context *subflow;
+	struct sock *sk = (struct sock *)msk;
+	bool has_id_0 = false;
+	int err = -EINVAL;
+
+	lock_sock(sk);
+	mptcp_for_each_subflow(msk, subflow) {
+		if (subflow->local_id == 0) {
+			has_id_0 = true;
+			break;
+		}
+	}
+	if (!has_id_0) {
+		GENL_SET_ERR_MSG(info, "address with id 0 not found");
+		goto remove_err;
+	}
+
+	list.ids[list.nr++] = 0;
+
+	spin_lock_bh(&msk->pm.lock);
+	mptcp_pm_remove_addr(msk, &list);
+	spin_unlock_bh(&msk->pm.lock);
+
+	err = 0;
+
+remove_err:
+	release_sock(sk);
+	return err;
+}
+
 int mptcp_pm_nl_remove_doit(struct sk_buff *skb, struct genl_info *info)
 {
 	struct nlattr *token = info->attrs[MPTCP_PM_ATTR_TOKEN];
@@ -239,6 +273,11 @@  int mptcp_pm_nl_remove_doit(struct sk_buff *skb, struct genl_info *info)
 		goto remove_err;
 	}
 
+	if (id_val == 0) {
+		err = mptcp_userspace_pm_remove_id_zero_address(msk, info);
+		goto remove_err;
+	}
+
 	lock_sock((struct sock *)msk);
 
 	list_for_each_entry(entry, &msk->pm.userspace_pm_local_addr_list, list) {