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(+)

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) {

-- 
2.41.0

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?

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

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.

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

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.

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