MPTCP Linux Development
 help / color / mirror / Atom feed
* [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR
@ 2025-04-02  2:53 Geliang Tang
  2025-04-02  2:53 ` [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR Geliang Tang
                   ` (4 more replies)
  0 siblings, 5 replies; 9+ messages in thread
From: Geliang Tang @ 2025-04-02  2:53 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang

From: Geliang Tang <tanggeliang@kylinos.cn>

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/403

Geliang Tang (3):
  mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR
  mptcp: pm: userspace: drop delete_local_addr helper
  selftests: mptcp: send REMOVE_ADDR after subflow is deleted

 net/mptcp/pm_userspace.c                      | 37 +++----------------
 .../testing/selftests/net/mptcp/mptcp_join.sh |  4 +-
 .../selftests/net/mptcp/userspace_pm.sh       |  6 +++
 3 files changed, 14 insertions(+), 33 deletions(-)

-- 
2.43.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR
  2025-04-02  2:53 [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR Geliang Tang
@ 2025-04-02  2:53 ` Geliang Tang
  2025-04-08 23:51   ` Mat Martineau
  2025-04-02  2:53 ` [PATCH mptcp-next 2/3] mptcp: pm: userspace: drop delete_local_addr helper Geliang Tang
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 9+ messages in thread
From: Geliang Tang @ 2025-04-02  2:53 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang

From: Geliang Tang <tanggeliang@kylinos.cn>

Address entries are removed from local_addr_list when sending a REMOVE_ADDR
by the userspace PM, the local_addr_used counter of PM should also be
decremented accordingly.

Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 net/mptcp/pm_userspace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
index 7fc19b844384..db471eb836b3 100644
--- a/net/mptcp/pm_userspace.c
+++ b/net/mptcp/pm_userspace.c
@@ -331,6 +331,7 @@ int mptcp_pm_nl_remove_doit(struct sk_buff *skb, struct genl_info *info)
 	}
 
 	list_del_rcu(&match->list);
+	msk->pm.local_addr_used--;
 	spin_unlock_bh(&msk->pm.lock);
 
 	mptcp_pm_remove_addr_entry(msk, match);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH mptcp-next 2/3] mptcp: pm: userspace: drop delete_local_addr helper
  2025-04-02  2:53 [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR Geliang Tang
  2025-04-02  2:53 ` [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR Geliang Tang
@ 2025-04-02  2:53 ` Geliang Tang
  2025-04-02  2:53 ` [PATCH mptcp-next 3/3] selftests: mptcp: send REMOVE_ADDR after subflow is deleted Geliang Tang
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 9+ messages in thread
From: Geliang Tang @ 2025-04-02  2:53 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang

From: Geliang Tang <tanggeliang@kylinos.cn>

Address entries should not be removed from local_addr_list when a subflow
is deleted by the userspace PM, should only be removed when sending a
REMOVE_ADDR.

So mptcp_userspace_pm_delete_local_addr() helper shouldn't be called in
mptcp_pm_nl_subflow_create_doit() and mptcp_pm_nl_subflow_destroy_doit().

Since this helper is open-coding in mptcp_pm_nl_remove_doit(), it can be
dropped now.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/403
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 net/mptcp/pm_userspace.c | 36 ++++--------------------------------
 1 file changed, 4 insertions(+), 32 deletions(-)

diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
index db471eb836b3..3824b4165421 100644
--- a/net/mptcp/pm_userspace.c
+++ b/net/mptcp/pm_userspace.c
@@ -90,30 +90,6 @@ static int mptcp_userspace_pm_append_new_local_addr(struct mptcp_sock *msk,
 	return ret;
 }
 
-/* If the subflow is closed from the other peer (not via a
- * subflow destroy command then), we want to keep the entry
- * not to assign the same ID to another address and to be
- * able to send RM_ADDR after the removal of the subflow.
- */
-static int mptcp_userspace_pm_delete_local_addr(struct mptcp_sock *msk,
-						struct mptcp_pm_addr_entry *addr)
-{
-	struct sock *sk = (struct sock *)msk;
-	struct mptcp_pm_addr_entry *entry;
-
-	entry = mptcp_userspace_pm_lookup_addr(msk, &addr->addr);
-	if (!entry)
-		return -EINVAL;
-
-	/* TODO: a refcount is needed because the entry can
-	 * be used multiple times (e.g. fullmesh mode).
-	 */
-	list_del_rcu(&entry->list);
-	sock_kfree_s(sk, entry, sizeof(*entry));
-	msk->pm.local_addr_used--;
-	return 0;
-}
-
 static struct mptcp_pm_addr_entry *
 mptcp_userspace_pm_lookup_addr_by_id(struct mptcp_sock *msk, unsigned int id)
 {
@@ -409,14 +385,13 @@ int mptcp_pm_nl_subflow_create_doit(struct sk_buff *skb, struct genl_info *info)
 	err = __mptcp_subflow_connect(sk, &local, &addr_r);
 	release_sock(sk);
 
-	if (err)
+	if (err) {
 		GENL_SET_ERR_MSG_FMT(info, "connect error: %d", err);
+		goto create_err;
+	}
 
 	spin_lock_bh(&msk->pm.lock);
-	if (err)
-		mptcp_userspace_pm_delete_local_addr(msk, &entry);
-	else
-		msk->pm.subflows++;
+	msk->pm.subflows++;
 	spin_unlock_bh(&msk->pm.lock);
 
  create_err:
@@ -535,9 +510,6 @@ int mptcp_pm_nl_subflow_destroy_doit(struct sk_buff *skb, struct genl_info *info
 		goto release_sock;
 	}
 
-	spin_lock_bh(&msk->pm.lock);
-	mptcp_userspace_pm_delete_local_addr(msk, &addr_l);
-	spin_unlock_bh(&msk->pm.lock);
 	mptcp_subflow_shutdown(sk, ssk, RCV_SHUTDOWN | SEND_SHUTDOWN);
 	mptcp_close_ssk(sk, ssk, mptcp_subflow_ctx(ssk));
 	MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RMSUBFLOW);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH mptcp-next 3/3] selftests: mptcp: send REMOVE_ADDR after subflow is deleted
  2025-04-02  2:53 [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR Geliang Tang
  2025-04-02  2:53 ` [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR Geliang Tang
  2025-04-02  2:53 ` [PATCH mptcp-next 2/3] mptcp: pm: userspace: drop delete_local_addr helper Geliang Tang
@ 2025-04-02  2:53 ` Geliang Tang
  2025-04-02  4:01 ` [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR MPTCP CI
  2025-04-09  0:23 ` Mat Martineau
  4 siblings, 0 replies; 9+ messages in thread
From: Geliang Tang @ 2025-04-02  2:53 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang

From: Geliang Tang <tanggeliang@kylinos.cn>

Now address entries only be removed from local_addr_list when sending a
REMOVE_ADDR by the userspace PM, they're no longer removed when a subflow
is deleted.

To make the original userspace PM selftests pass, this patch always sends
a REMOVE_ADDR when a subflow is deleted.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh   | 4 +++-
 tools/testing/selftests/net/mptcp/userspace_pm.sh | 6 ++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index b8af65373b3a..c138b4913ad8 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -3624,11 +3624,12 @@ userspace_tests()
 		userspace_pm_chk_get_addr "${ns1}" "10" "id 10 flags signal 10.0.2.1"
 		userspace_pm_chk_get_addr "${ns1}" "20" "id 20 flags signal 10.0.3.1"
 		userspace_pm_rm_sf $ns1 "::ffff:10.0.2.1" $MPTCP_LIB_EVENT_SUB_ESTABLISHED
+		userspace_pm_rm_addr $ns1 10
 		userspace_pm_chk_dump_addr "${ns1}" \
 			"id 20 flags signal 10.0.3.1" "after rm_sf 10"
 		userspace_pm_rm_addr $ns1 20
 		userspace_pm_chk_dump_addr "${ns1}" "" "after rm_addr 20"
-		chk_rm_nr 1 1 invert
+		chk_rm_nr 2 1 invert
 		chk_mptcp_info subflows 0 subflows 0
 		chk_subflows_total 1 1
 		kill_events_pids
@@ -3653,6 +3654,7 @@ userspace_tests()
 			"subflow"
 		userspace_pm_chk_get_addr "${ns2}" "20" "id 20 flags subflow 10.0.3.2"
 		userspace_pm_rm_sf $ns2 10.0.3.2 $MPTCP_LIB_EVENT_SUB_ESTABLISHED
+		userspace_pm_rm_addr $ns2 20
 		userspace_pm_chk_dump_addr "${ns2}" \
 			"" \
 			"after rm_sf 20"
diff --git a/tools/testing/selftests/net/mptcp/userspace_pm.sh b/tools/testing/selftests/net/mptcp/userspace_pm.sh
index 333064b0b5ac..c16465c9c2ca 100755
--- a/tools/testing/selftests/net/mptcp/userspace_pm.sh
+++ b/tools/testing/selftests/net/mptcp/userspace_pm.sh
@@ -628,6 +628,7 @@ test_subflows()
 	:>"$server_evts"
 	ip netns exec "$ns1" ./pm_nl_ctl dsf lip dead:beef:2::1 lport "$sport" rip\
 	   dead:beef:2::2 rport "$client6_port" token "$server6_token"
+	ip netns exec "$ns1" ./pm_nl_ctl rem id 23 token "$server6_token"
 	sleep 0.5
 	verify_subflow_events "$server_evts" "$SUB_CLOSED" "$server6_token" "$AF_INET6"\
 			      "dead:beef:2::1" "dead:beef:2::2" "$client6_port" "23"\
@@ -667,6 +668,7 @@ test_subflows()
 	:>"$server_evts"
 	ip netns exec "$ns1" ./pm_nl_ctl dsf lip 10.0.2.1 lport "$sport" rip 10.0.2.2 rport\
 	   $new4_port token "$server4_token"
+	ip netns exec "$ns1" ./pm_nl_ctl rem id 23 token "$server4_token"
 	sleep 0.5
 	verify_subflow_events "$server_evts" "$SUB_CLOSED" "$server4_token" "$AF_INET" "10.0.2.1"\
 			      "10.0.2.2" "$new4_port" "23" "$client_addr_id" "ns1" "ns2"
@@ -705,6 +707,7 @@ test_subflows()
 	:>"$client_evts"
 	ip netns exec "$ns2" ./pm_nl_ctl dsf lip 10.0.2.2 lport "$sport" rip 10.0.2.1 rport\
 	   $app4_port token "$client4_token"
+	ip netns exec "$ns2" ./pm_nl_ctl rem id 23 token "$client4_token"
 	sleep 0.5
 	verify_subflow_events "$client_evts" "$SUB_CLOSED" "$client4_token" "$AF_INET" "10.0.2.2"\
 			      "10.0.2.1" "$app4_port" "23" "$server_addr_id" "ns2" "ns1"
@@ -744,6 +747,7 @@ test_subflows()
 	:>"$client_evts"
 	ip netns exec "$ns2" ./pm_nl_ctl dsf lip dead:beef:2::2 lport "$sport" rip\
 	   dead:beef:2::1 rport $app6_port token "$client6_token"
+	ip netns exec "$ns2" ./pm_nl_ctl rem id 23 token "$client6_token"
 	sleep 0.5
 	verify_subflow_events $client_evts $SUB_CLOSED $client6_token $AF_INET6 "dead:beef:2::2"\
 			      "dead:beef:2::1" "$app6_port" "23" "$server_addr_id" "ns2" "ns1"
@@ -781,6 +785,7 @@ test_subflows()
 	:>"$client_evts"
 	ip netns exec "$ns2" ./pm_nl_ctl dsf lip 10.0.2.2 lport "$sport" rip 10.0.2.1 rport\
 	   $new4_port token "$client4_token"
+	ip netns exec "$ns2" ./pm_nl_ctl rem id 23 token "$client4_token"
 	sleep 0.5
 	verify_subflow_events "$client_evts" "$SUB_CLOSED" "$client4_token" "$AF_INET" "10.0.2.2"\
 			      "10.0.2.1" "$new4_port" "23" "$server_addr_id" "ns2" "ns1"
@@ -827,6 +832,7 @@ test_subflows_v4_v6_mix()
 	:>"$client_evts"
 	ip netns exec "$ns2" ./pm_nl_ctl dsf lip 10.0.2.2 lport "$sport" rip 10.0.2.1 rport\
 	   $app6_port token "$client6_token"
+	ip netns exec "$ns2" ./pm_nl_ctl rem id 23 token "$client6_token"
 	sleep 0.5
 	verify_subflow_events "$client_evts" "$SUB_CLOSED" "$client6_token" \
 			      "$AF_INET" "10.0.2.2" "10.0.2.1" "$app6_port" "23"\
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR
  2025-04-02  2:53 [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR Geliang Tang
                   ` (2 preceding siblings ...)
  2025-04-02  2:53 ` [PATCH mptcp-next 3/3] selftests: mptcp: send REMOVE_ADDR after subflow is deleted Geliang Tang
@ 2025-04-02  4:01 ` MPTCP CI
  2025-04-09  0:23 ` Mat Martineau
  4 siblings, 0 replies; 9+ messages in thread
From: MPTCP CI @ 2025-04-02  4:01 UTC (permalink / raw)
  To: Geliang Tang; +Cc: mptcp

Hi Geliang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal: Unstable: 1 failed test(s): selftest_mptcp_connect 🔴
- KVM Validation: debug: Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/14210668405

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/8f913c652044
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=949152


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR
  2025-04-02  2:53 ` [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR Geliang Tang
@ 2025-04-08 23:51   ` Mat Martineau
  2025-04-09  6:50     ` Geliang Tang
  0 siblings, 1 reply; 9+ messages in thread
From: Mat Martineau @ 2025-04-08 23:51 UTC (permalink / raw)
  To: Geliang Tang; +Cc: mptcp, Geliang Tang

On Wed, 2 Apr 2025, Geliang Tang wrote:

> From: Geliang Tang <tanggeliang@kylinos.cn>
>
> Address entries are removed from local_addr_list when sending a REMOVE_ADDR
> by the userspace PM, the local_addr_used counter of PM should also be
> decremented accordingly.
>
> Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
> net/mptcp/pm_userspace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
> index 7fc19b844384..db471eb836b3 100644
> --- a/net/mptcp/pm_userspace.c
> +++ b/net/mptcp/pm_userspace.c
> @@ -331,6 +331,7 @@ int mptcp_pm_nl_remove_doit(struct sk_buff *skb, struct genl_info *info)
> 	}
>
> 	list_del_rcu(&match->list);
> +	msk->pm.local_addr_used--;
> 	spin_unlock_bh(&msk->pm.lock);
>
> 	mptcp_pm_remove_addr_entry(msk, match);


Hi Geliang -

This should be squashed with patch 2, since it's not bisectable (wouldn't 
want this patch to get cherry-picked without the other, and have the 
variable decremented twice).



- Mat

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR
  2025-04-02  2:53 [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR Geliang Tang
                   ` (3 preceding siblings ...)
  2025-04-02  4:01 ` [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR MPTCP CI
@ 2025-04-09  0:23 ` Mat Martineau
  2025-04-09  7:02   ` Geliang Tang
  4 siblings, 1 reply; 9+ messages in thread
From: Mat Martineau @ 2025-04-09  0:23 UTC (permalink / raw)
  To: Geliang Tang, Matthieu Baerts; +Cc: mptcp, Geliang Tang

On Wed, 2 Apr 2025, Geliang Tang wrote:

> From: Geliang Tang <tanggeliang@kylinos.cn>
>
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/403

Geliang and Matthieu -

Since this is a bug fix, should it go to mptcp-net rather than -next? Or 
does the associated selftest change make that complicated?

I think there's a nearby bug in mptcp_pm_nl_remove_doit() that I noticed 
while reviewing this series. If we upstream this series to the net tree it 
might make sense to send the fixes together.

In this code:

 	list_del_rcu(&match->list);
 	msk->pm.local_addr_used--;
 	spin_unlock_bh(&msk->pm.lock);

 	mptcp_pm_remove_addr_entry(msk, match);

 	release_sock(sk);

 	sock_kfree_s(sk, match, sizeof(*match));

The struct is removed from a linked list with list_del_rcu(), but doesn't 
wait for a grace period before the sock_kfree_s() in the final line. The 
easy solution is to make the kfree rcu-aware and open-code the handling of 
sk_omem_alloc, like this:

 	atomic_sub(sizeof(*match), &sk->sk_omem_alloc);
 	kfree_rcu(match);

instead of calling sock_kfree_s(). tcp_md5_do_del() takes this approach. 
This does allow possible allocation beyond the optmem limit, but only for 
the duration of the rcu grace period.

I can send a patch tomorrow, unless someone wants to implement it before 
then.


- Mat


>
> Geliang Tang (3):
>  mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR
>  mptcp: pm: userspace: drop delete_local_addr helper
>  selftests: mptcp: send REMOVE_ADDR after subflow is deleted
>
> net/mptcp/pm_userspace.c                      | 37 +++----------------
> .../testing/selftests/net/mptcp/mptcp_join.sh |  4 +-
> .../selftests/net/mptcp/userspace_pm.sh       |  6 +++
> 3 files changed, 14 insertions(+), 33 deletions(-)
>
> -- 
> 2.43.0
>
>
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR
  2025-04-08 23:51   ` Mat Martineau
@ 2025-04-09  6:50     ` Geliang Tang
  0 siblings, 0 replies; 9+ messages in thread
From: Geliang Tang @ 2025-04-09  6:50 UTC (permalink / raw)
  To: Mat Martineau; +Cc: mptcp, Geliang Tang

Hi Mat,

Thanks for the review.

On Tue, 2025-04-08 at 16:51 -0700, Mat Martineau wrote:
> On Wed, 2 Apr 2025, Geliang Tang wrote:
> 
> > From: Geliang Tang <tanggeliang@kylinos.cn>
> > 
> > Address entries are removed from local_addr_list when sending a
> > REMOVE_ADDR
> > by the userspace PM, the local_addr_used counter of PM should also
> > be
> > decremented accordingly.
> > 
> > Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
> > Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> > ---
> > net/mptcp/pm_userspace.c | 1 +
> > 1 file changed, 1 insertion(+)
> > 
> > diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
> > index 7fc19b844384..db471eb836b3 100644
> > --- a/net/mptcp/pm_userspace.c
> > +++ b/net/mptcp/pm_userspace.c
> > @@ -331,6 +331,7 @@ int mptcp_pm_nl_remove_doit(struct sk_buff
> > *skb, struct genl_info *info)
> > 	}
> > 
> > 	list_del_rcu(&match->list);
> > +	msk->pm.local_addr_used--;
> > 	spin_unlock_bh(&msk->pm.lock);
> > 
> > 	mptcp_pm_remove_addr_entry(msk, match);
> 
> 
> Hi Geliang -
> 
> This should be squashed with patch 2, since it's not bisectable

Sure. Will squash it in v2.

Thanks,
-Geliang

> (wouldn't 
> want this patch to get cherry-picked without the other, and have the 
> variable decremented twice).
> 
> 
> 
> - Mat


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR
  2025-04-09  0:23 ` Mat Martineau
@ 2025-04-09  7:02   ` Geliang Tang
  0 siblings, 0 replies; 9+ messages in thread
From: Geliang Tang @ 2025-04-09  7:02 UTC (permalink / raw)
  To: Mat Martineau, Matthieu Baerts; +Cc: mptcp, Geliang Tang

Hi Mat,

On Tue, 2025-04-08 at 17:23 -0700, Mat Martineau wrote:
> On Wed, 2 Apr 2025, Geliang Tang wrote:
> 
> > From: Geliang Tang <tanggeliang@kylinos.cn>
> > 
> > Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/403
> 
> Geliang and Matthieu -
> 
> Since this is a bug fix, should it go to mptcp-net rather than -next?
> Or 
> does the associated selftest change make that complicated?
> 
> I think there's a nearby bug in mptcp_pm_nl_remove_doit() that I
> noticed 
> while reviewing this series. If we upstream this series to the net
> tree it 
> might make sense to send the fixes together.
> 
> In this code:
> 
>  	list_del_rcu(&match->list);
>  	msk->pm.local_addr_used--;
>  	spin_unlock_bh(&msk->pm.lock);
> 
>  	mptcp_pm_remove_addr_entry(msk, match);
> 
>  	release_sock(sk);
> 
>  	sock_kfree_s(sk, match, sizeof(*match));
> 
> The struct is removed from a linked list with list_del_rcu(), but
> doesn't 
> wait for a grace period before the sock_kfree_s() in the final line.
> The 
> easy solution is to make the kfree rcu-aware and open-code the
> handling of 
> sk_omem_alloc, like this:
> 
>  	atomic_sub(sizeof(*match), &sk->sk_omem_alloc);
>  	kfree_rcu(match);

How about adding a new helper sock_kfree_rcu_s() here?

> 
> instead of calling sock_kfree_s(). tcp_md5_do_del() takes this
> approach. 
> This does allow possible allocation beyond the optmem limit, but only
> for 
> the duration of the rcu grace period.
> 
> I can send a patch tomorrow, unless someone wants to implement it
> before 

Great! Looking forward to your patch.

Thanks,
-Geliang

> then.
> 
> 
> - Mat
> 
> 
> > 
> > Geliang Tang (3):
> >  mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR
> >  mptcp: pm: userspace: drop delete_local_addr helper
> >  selftests: mptcp: send REMOVE_ADDR after subflow is deleted
> > 
> > net/mptcp/pm_userspace.c                      | 37 +++-------------
> > ---
> > .../testing/selftests/net/mptcp/mptcp_join.sh |  4 +-
> > .../selftests/net/mptcp/userspace_pm.sh       |  6 +++
> > 3 files changed, 14 insertions(+), 33 deletions(-)
> > 
> > -- 
> > 2.43.0
> > 
> > 
> > 


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2025-04-09  7:02 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-02  2:53 [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR Geliang Tang
2025-04-02  2:53 ` [PATCH mptcp-next 1/3] mptcp: pm: userspace: local_addr_used-- after sending REMOVE_ADDR Geliang Tang
2025-04-08 23:51   ` Mat Martineau
2025-04-09  6:50     ` Geliang Tang
2025-04-02  2:53 ` [PATCH mptcp-next 2/3] mptcp: pm: userspace: drop delete_local_addr helper Geliang Tang
2025-04-02  2:53 ` [PATCH mptcp-next 3/3] selftests: mptcp: send REMOVE_ADDR after subflow is deleted Geliang Tang
2025-04-02  4:01 ` [PATCH mptcp-next 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR MPTCP CI
2025-04-09  0:23 ` Mat Martineau
2025-04-09  7:02   ` Geliang Tang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox