mbox series

[mptcp-next,0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR

Message ID cover.1743562290.git.tanggeliang@kylinos.cn (mailing list archive)
Headers show
Series only remove entry from local_addr_list when sending a REMOVE_ADDR | expand

Message

Geliang Tang April 2, 2025, 2:53 a.m. UTC
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(-)

Comments

MPTCP CI April 2, 2025, 4:01 a.m. UTC | #1
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 
Mat Martineau April 9, 2025, 12:23 a.m. UTC | #2
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
>
>
>
Geliang Tang April 9, 2025, 7:02 a.m. UTC | #3
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
> > 
> > 
> >