From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Florian Westphal <fw@strlen.de>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v2 4/5] mptcp: add MPTCP_SUBFLOW_ADDRS getsockopt support
Date: Tue, 17 Aug 2021 17:31:19 -0700 (PDT) [thread overview]
Message-ID: <98a76020-a5b2-63c8-b44d-a5131e84bc26@linux.intel.com> (raw)
In-Reply-To: <20210816162636.25611-5-fw@strlen.de>
On Mon, 16 Aug 2021, Florian Westphal wrote:
> This retrieves the address pairs of all subflows currently
> active for a given mptcp connection.
>
> It re-uses the same meta-header as for MPTCP_TCPINFO.
>
> A new structure is provided to hold the subflow
> address data:
>
> struct mptcp_subflow_addrs {
> union {
> sa_family_t sa_family;
Looks like the update to __kernel_sa_family_t was in the code but not the
comment.
> struct sockaddr sa_local;
> struct sockaddr_in sin_local;
> struct sockaddr_in6 sin6_local;
> struct sockaddr_storage ss_local;
> };
> union {
> struct sockaddr sa_remote;
> struct sockaddr_in sin_remote;
> struct sockaddr_in6 sin6_remote;
> struct sockaddr_storage ss_remote;
> };
> };
>
> Usage of the new getsockopt is very similar to
> MPTCP_TCPINFO one.
>
> Userspace allocates a
> 'struct mptcp_subflow_data', followed by one or
> more 'struct mptcp_subflow_addrs', then inits the
> mptcp_subflow_data structure as follows:
>
> struct mptcp_subflow_addrs *sf_addr;
> struct mptcp_subflow_data *addr;
> socklen_t olen = sizeof(*addr) + (8 * sizeof(*sf_addr));
>
> addr = malloc(olen);
> addr->size_subflow_data = sizeof(*addr);
> addr->num_subflows = 0;
> addr->size_kernel = 0;
> addr->size_user = sizeof(struct mptcp_subflow_addrs);
>
> sf_addr = (struct mptcp_subflow_addrs *)(addr + 1);
>
> and then retrieves the endpoint addresses via:
> ret = getsockopt(fd, SOL_MPTCP, MPTCP_SUBFLOW_ADDRS,
> addr, &olen);
>
> If the call succeeds, kernel will have added up to 8
> endpoint addresses after the 'mptcp_subflow_data' header.
>
> Userspace needs to re-check 'olen' value to detect how
> many bytes have been filled in by the kernel.
>
> Userspace can check addr->num_subflows to discover when
> there were more subflows that available data space.
^^^^ than?
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> include/uapi/linux/mptcp.h | 17 +++++++
> net/mptcp/sockopt.c | 91 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 108 insertions(+)
>
> diff --git a/include/uapi/linux/mptcp.h b/include/uapi/linux/mptcp.h
> index 7c368fccd83e..c368c11a0ed9 100644
> --- a/include/uapi/linux/mptcp.h
> +++ b/include/uapi/linux/mptcp.h
> @@ -201,8 +201,25 @@ struct mptcp_subflow_data {
> __u32 size_user; /* size of one element in data[] */
> } __attribute__((aligned(8)));
>
> +struct mptcp_subflow_addrs {
> + union {
> + __kernel_sa_family_t sa_family;
> + struct sockaddr sa_local;
> + struct sockaddr_in sin_local;
> + struct sockaddr_in6 sin6_local;
> + struct sockaddr_storage ss_local;
> + };
> + union {
> + struct sockaddr sa_remote;
> + struct sockaddr_in sin_remote;
> + struct sockaddr_in6 sin6_remote;
> + struct sockaddr_storage ss_remote;
> + };
> +};
> +
> /* MPTCP socket options */
> #define MPTCP_INFO 1
> #define MPTCP_TCPINFO 2
> +#define MPTCP_SUBFLOW_ADDRS 3
>
> #endif /* _UAPI_MPTCP_H */
> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index 77838933760c..51c488108b80 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -840,6 +840,95 @@ static int mptcp_getsockopt_tcpinfo(struct mptcp_sock *msk, char __user *optval,
> return 0;
> }
>
> +static void mptcp_get_sub_addrs(const struct sock *sk, struct mptcp_subflow_addrs *a)
> +{
> + struct inet_sock *inet = inet_sk(sk);
> +
> + memset(a, 0, sizeof(*a));
> +
> + if (sk->sk_family == AF_INET) {
> + a->sin_local.sin_family = AF_INET;
> + a->sin_local.sin_port = inet->inet_sport;
> + a->sin_local.sin_addr.s_addr = inet->inet_rcv_saddr;
> +
> + if (!a->sin_local.sin_addr.s_addr)
> + a->sin_local.sin_addr.s_addr = inet->inet_saddr;
> +
> + a->sin_remote.sin_family = AF_INET;
> + a->sin_remote.sin_port = inet->inet_dport;
> + a->sin_remote.sin_addr.s_addr = inet->inet_daddr;
> +#if IS_ENABLED(CONFIG_IPV6)
> + } else if (sk->sk_family == AF_INET6) {
> + const struct ipv6_pinfo *np = inet6_sk(sk);
> +
> + a->sin6_local.sin6_family = AF_INET6;
> + a->sin6_local.sin6_port = inet->inet_sport;
> +
> + if (ipv6_addr_any(&sk->sk_v6_rcv_saddr))
> + a->sin6_local.sin6_addr = np->saddr;
> + else
> + a->sin6_local.sin6_addr = sk->sk_v6_rcv_saddr;
> +
> + a->sin6_remote.sin6_family = AF_INET6;
> + a->sin6_remote.sin6_port = inet->inet_dport;
> + a->sin6_remote.sin6_addr = sk->sk_v6_daddr;
> +#endif
> + }
> +}
> +
> +static int mptcp_getsockopt_subflow_addrs(struct mptcp_sock *msk, char __user *optval,
> + int __user *optlen)
> +{
> + struct mptcp_subflow_context *subflow;
> + struct sock *sk = &msk->sk.icsk_inet.sk;
Reverse-xmas...
Other than these minor things, the kernel code looks good in patches 1-4.
-Mat
> + unsigned int sfcount = 0, copied = 0;
> + struct mptcp_subflow_data sfd;
> + char __user *addrptr;
> + int len;
> +
> + len = mptcp_get_subflow_data(&sfd, optval, optlen);
> + if (len < 0)
> + return len;
> +
> + sfd.size_kernel = sizeof(struct mptcp_subflow_addrs);
> + sfd.size_user = min_t(unsigned int, sfd.size_user,
> + sizeof(struct mptcp_subflow_addrs));
> +
> + addrptr = optval + sfd.size_subflow_data;
> +
> + lock_sock(sk);
> +
> + mptcp_for_each_subflow(msk, subflow) {
> + struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
> +
> + ++sfcount;
> +
> + if (len && len >= sfd.size_user) {
> + struct mptcp_subflow_addrs a;
> +
> + mptcp_get_sub_addrs(ssk, &a);
> +
> + if (copy_to_user(addrptr, &a, sfd.size_user)) {
> + release_sock(sk);
> + return -EFAULT;
> + }
> +
> + addrptr += sfd.size_user;
> + copied += sfd.size_user;
> + len -= sfd.size_user;
> + }
> + }
> +
> + release_sock(sk);
> +
> + sfd.num_subflows = sfcount;
> +
> + if (mptcp_put_subflow_data(&sfd, optval, copied, optlen))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static int mptcp_getsockopt_sol_tcp(struct mptcp_sock *msk, int optname,
> char __user *optval, int __user *optlen)
> {
> @@ -862,6 +951,8 @@ static int mptcp_getsockopt_sol_mptcp(struct mptcp_sock *msk, int optname,
> return mptcp_getsockopt_info(msk, optval, optlen);
> case MPTCP_TCPINFO:
> return mptcp_getsockopt_tcpinfo(msk, optval, optlen);
> + case MPTCP_SUBFLOW_ADDRS:
> + return mptcp_getsockopt_subflow_addrs(msk, optval, optlen);
> }
>
> return -EOPNOTSUPP;
> --
> 2.31.1
>
>
>
--
Mat Martineau
Intel
next prev parent reply other threads:[~2021-08-18 0:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-16 16:26 [PATCH mptcp-next v2 0/5] mptcp: add SOL_MPTCP getsockopt support Florian Westphal
2021-08-16 16:26 ` [PATCH mptcp-next v2 1/5] mptcp: add new mptcp_fill_diag helper Florian Westphal
2021-08-16 16:26 ` [PATCH mptcp-next v2 2/5] mptcp: add MPTCP_INFO getsockopt Florian Westphal
2021-08-16 16:26 ` [PATCH mptcp-next v2 3/5] mptcp: add MPTCP_TCPINFO getsockopt support Florian Westphal
2021-08-18 0:54 ` Mat Martineau
2021-08-16 16:26 ` [PATCH mptcp-next v2 4/5] mptcp: add MPTCP_SUBFLOW_ADDRS " Florian Westphal
2021-08-18 0:31 ` Mat Martineau [this message]
2021-08-16 16:26 ` [PATCH mptcp-next v2 5/5] selftests: mptcp: add mptcp getsockopt test cases Florian Westphal
2021-08-17 2:17 ` kernel test robot
2021-08-18 0:51 ` Mat Martineau
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=98a76020-a5b2-63c8-b44d-a5131e84bc26@linux.intel.com \
--to=mathew.j.martineau@linux.intel.com \
--cc=fw@strlen.de \
--cc=mptcp@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox