MPTCP Linux Development
 help / color / mirror / Atom feed
* [MPTCP] Re: [MPTCP][PATCH v3 mptcp-next 1/4] mptcp: move to next addr when subflow creation fail
@ 2021-02-09 22:51 Mat Martineau
  0 siblings, 0 replies; only message in thread
From: Mat Martineau @ 2021-02-09 22:51 UTC (permalink / raw)
  To: mptcp 

[-- Attachment #1: Type: text/plain, Size: 4375 bytes --]

On Tue, 9 Feb 2021, Geliang Tang wrote:

> When an invalid address was announced, the subflow couldn't be created
> for this address. Therefore mptcp_pm_nl_subflow_established couldn't be
> invoked. Then the next addresses in the local address list didn't have a
> chance to be announced.
>
> This patch invokes the new function mptcp_pm_add_addr_echoed when the
> address is echoed. In it, use lookup_subflow_by_saddr to check whether
> this address is in the conn_list. If it isn't, PM schedules the status
> MPTCP_PM_ESTABLISHED to invoke mptcp_pm_create_subflow_or_signal_addr
> to deal with the next address in the local address list.
>
> Signed-off-by: Geliang Tang <geliangtang(a)gmail.com>
> ---
> net/mptcp/options.c    |  1 +
> net/mptcp/pm.c         | 18 ++++++++++++++++++
> net/mptcp/pm_netlink.c |  4 ++--
> net/mptcp/protocol.h   |  3 +++
> 4 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
> index b63574d6b812..41bcfcc3afe2 100644
> --- a/net/mptcp/options.c
> +++ b/net/mptcp/options.c
> @@ -1022,6 +1022,7 @@ void mptcp_incoming_options(struct sock *sk, struct sk_buff *skb)
> 			mptcp_pm_add_addr_received(msk, &addr);
> 			MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_ADDADDR);
> 		} else {
> +			mptcp_pm_add_addr_echoed(msk, &addr);
> 			mptcp_pm_del_add_timer(msk, &addr);
> 			MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_ECHOADD);
> 		}
> diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
> index 6fd4b2c1b076..280cc7758f31 100644
> --- a/net/mptcp/pm.c
> +++ b/net/mptcp/pm.c
> @@ -197,6 +197,24 @@ void mptcp_pm_add_addr_received(struct mptcp_sock *msk,
> 	spin_unlock_bh(&pm->lock);
> }
>
> +void mptcp_pm_add_addr_echoed(struct mptcp_sock *msk, struct mptcp_addr_info *addr)
> +{
> +	struct sock *sk = (struct sock *)msk;
> +	struct mptcp_pm_data *pm = &msk->pm;
> +
> +	pr_debug("msk=%p", msk);
> +
> +	spin_lock_bh(&pm->lock);
> +
> +	bh_lock_sock(sk);

Adding the msk lock is more complex than this, because acquiring the msk 
lock while a subflow lock is held risks deadlock - and the subflow lock is 
already held here. This is why we need the deferred events or workqueue 
for things like retransmit.

Is the conn_list / join_list check really needed? Would it work to check 
against the anno_list to validate that that the echo matches an ADD_ADDR 
that was sent, before scheduling the worker? The path manager on the peer 
doesn't have to immediately connect when it receives an ADD_ADDR - it 
doesn't seem to make sense to wait for a connection except as a way to 
deal with a peer that doesn't send ADD_ADDR echoes (or if there are lost 
echoes).

Mat


> +	__mptcp_flush_join_list(msk);
> +	if (!lookup_subflow_by_saddr(&msk->conn_list, addr))
> +		mptcp_pm_schedule_work(msk, MPTCP_PM_ESTABLISHED);
> +	bh_unlock_sock(sk);
> +
> +	spin_unlock_bh(&pm->lock);
> +}
> +
> void mptcp_pm_add_addr_send_ack(struct mptcp_sock *msk)
> {
> 	if (!mptcp_pm_should_add_signal(msk))
> diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
> index 8e8e35fa4002..97adae0c3b0e 100644
> --- a/net/mptcp/pm_netlink.c
> +++ b/net/mptcp/pm_netlink.c
> @@ -122,8 +122,8 @@ static void remote_address(const struct sock_common *skc,
> #endif
> }
>
> -static bool lookup_subflow_by_saddr(const struct list_head *list,
> -				    struct mptcp_addr_info *saddr)
> +bool lookup_subflow_by_saddr(const struct list_head *list,
> +			     struct mptcp_addr_info *saddr)
> {
> 	struct mptcp_subflow_context *subflow;
> 	struct mptcp_addr_info cur;
> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index 91827d949766..192dd30a85fe 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -651,6 +651,9 @@ void mptcp_pm_mp_prio_received(struct sock *sk, u8 bkup);
> int mptcp_pm_nl_mp_prio_send_ack(struct mptcp_sock *msk,
> 				 struct mptcp_addr_info *addr,
> 				 u8 bkup);
> +void mptcp_pm_add_addr_echoed(struct mptcp_sock *msk, struct mptcp_addr_info *addr);
> +bool lookup_subflow_by_saddr(const struct list_head *list,
> +			     struct mptcp_addr_info *saddr);
> void mptcp_pm_free_anno_list(struct mptcp_sock *msk);
> bool mptcp_pm_sport_in_anno_list(struct mptcp_sock *msk, const struct sock *sk);
> struct mptcp_pm_add_entry *
> -- 
> 2.29.2

--
Mat Martineau
Intel

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-02-09 22:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-09 22:51 [MPTCP] Re: [MPTCP][PATCH v3 mptcp-next 1/4] mptcp: move to next addr when subflow creation fail Mat Martineau

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