From: Mat Martineau <mathew.j.martineau at linux.intel.com>
To: mptcp at lists.01.org
Subject: [MPTCP] Re: [MPTCP][PATCH v3 mptcp-next 3/9] mptcp: use rm_ids array in mptcp_options_received
Date: Thu, 04 Feb 2021 16:20:22 -0800 [thread overview]
Message-ID: <36c2fbb4-4c34-4b1c-37dc-4a1816b51032@linux.intel.com> (raw)
In-Reply-To: 098e4b48d30601d1714b36f6839f5b7d5ff0a4c6.1612250255.git.geliangtang@gmail.com
[-- Attachment #1: Type: text/plain, Size: 4392 bytes --]
On Tue, 2 Feb 2021, Geliang Tang wrote:
> This patch changed the member rm_id in struct mptcp_options_received as an
> array of the removing address ids, and renamed it to rm_ids.
>
> In mptcp_parse_option, parsed the RM_ADDR suboption and filled them into
> the ids array in struct mptcp_options_received.
>
> In mptcp_incoming_options, passed this ids array to the function
> mptcp_pm_rm_addr_received.
>
> It alse changed the parameter type of mptcp_pm_rm_addr_received.
>
> Signed-off-by: Geliang Tang <geliangtang(a)gmail.com>
> ---
> net/mptcp/options.c | 15 +++++++++++----
> net/mptcp/pm.c | 10 ++++++----
> net/mptcp/protocol.h | 4 ++--
> 3 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
> index a6a4fdf03d6c..ed2b8af89ab8 100644
> --- a/net/mptcp/options.c
> +++ b/net/mptcp/options.c
> @@ -26,6 +26,7 @@ static void mptcp_parse_option(const struct sk_buff *skb,
> int expected_opsize;
> u8 version;
> u8 flags;
> + u8 i, nr;
>
> switch (subtype) {
> case MPTCPOPT_MP_CAPABLE:
> @@ -272,14 +273,20 @@ static void mptcp_parse_option(const struct sk_buff *skb,
> break;
>
> case MPTCPOPT_RM_ADDR:
> - if (opsize != TCPOLEN_MPTCP_RM_ADDR_BASE)
> + if (opsize < TCPOLEN_MPTCP_RM_ADDR_BASE + 1 ||
> + opsize > TCPOLEN_MPTCP_RM_ADDR_BASE + MPTCP_RM_IDS_MAX)
> break;
>
> ptr++;
>
> mp_opt->rm_addr = 1;
> - mp_opt->rm_id = *ptr++;
> - pr_debug("RM_ADDR: id=%d", mp_opt->rm_id);
> + memset(mp_opt->rm_ids, 0, MPTCP_RM_IDS_MAX);
> + nr = opsize - TCPOLEN_MPTCP_RM_ADDR_BASE;
> + for (i = 0; i < nr; i++)
> + mp_opt->rm_ids[i] = *ptr++;
> + pr_debug("RM_ADDR: ids_nr=%d", nr);
> + for (i = 0; i < nr; i++)
> + pr_debug(" -> id[%d]=%d", i, mp_opt->rm_ids[i]);
I think it's better to drop this pr_debug line, since the loop would still
iterate even when dynamic debug has substituted NOPs for this pr_debug
callsite.
Mat
> break;
>
> case MPTCPOPT_MP_PRIO:
> @@ -1040,7 +1047,7 @@ void mptcp_incoming_options(struct sock *sk, struct sk_buff *skb)
> }
>
> if (mp_opt.rm_addr) {
> - mptcp_pm_rm_addr_received(msk, mp_opt.rm_id);
> + mptcp_pm_rm_addr_received(msk, mp_opt.rm_ids);
> mp_opt.rm_addr = 0;
> }
>
> diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
> index 7207d1dc87ad..88bc35303f73 100644
> --- a/net/mptcp/pm.c
> +++ b/net/mptcp/pm.c
> @@ -205,17 +205,19 @@ void mptcp_pm_add_addr_send_ack(struct mptcp_sock *msk)
> mptcp_pm_schedule_work(msk, MPTCP_PM_ADD_ADDR_SEND_ACK);
> }
>
> -void mptcp_pm_rm_addr_received(struct mptcp_sock *msk, u8 rm_id)
> +void mptcp_pm_rm_addr_received(struct mptcp_sock *msk, u8 rm_ids[])
> {
> struct mptcp_pm_data *pm = &msk->pm;
> + u8 i;
>
> - pr_debug("msk=%p remote_id=%d", msk, rm_id);
> + pr_debug("msk=%p remote_ids_nr=%d", msk, mptcp_get_rm_ids_nr(rm_ids));
>
> - mptcp_event_addr_removed(msk, rm_id);
> + for (i = 0; i < MPTCP_RM_IDS_MAX && rm_ids[i]; i++)
> + mptcp_event_addr_removed(msk, rm_ids[i]);
>
> spin_lock_bh(&pm->lock);
> mptcp_pm_schedule_work(msk, MPTCP_PM_RM_ADDR_RECEIVED);
> - pm->rm_id = rm_id;
> + pm->rm_id = rm_ids[0];
> spin_unlock_bh(&pm->lock);
> }
>
> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index ae225ef202db..aeb589384824 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -140,7 +140,7 @@ struct mptcp_options_received {
> mpc_map:1,
> __unused:2;
> u8 addr_id;
> - u8 rm_id;
> + u8 rm_ids[MPTCP_RM_IDS_MAX];
> union {
> struct in_addr addr;
> #if IS_ENABLED(CONFIG_MPTCP_IPV6)
> @@ -661,7 +661,7 @@ void mptcp_pm_subflow_closed(struct mptcp_sock *msk, u8 id);
> void mptcp_pm_add_addr_received(struct mptcp_sock *msk,
> const struct mptcp_addr_info *addr);
> void mptcp_pm_add_addr_send_ack(struct mptcp_sock *msk);
> -void mptcp_pm_rm_addr_received(struct mptcp_sock *msk, u8 rm_id);
> +void mptcp_pm_rm_addr_received(struct mptcp_sock *msk, u8 rm_ids[]);
> 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,
> --
> 2.29.2
> _______________________________________________
> mptcp mailing list -- mptcp(a)lists.01.org
> To unsubscribe send an email to mptcp-leave(a)lists.01.org
>
--
Mat Martineau
Intel
reply other threads:[~2021-02-05 0:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36c2fbb4-4c34-4b1c-37dc-4a1816b51032@linux.intel.com \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.