From: Christoph Paasch <cpaasch at apple.com>
To: mptcp at lists.01.org
Subject: [MPTCP] Re: [PATCH net-next v2 1/3] mptcp: add new sock flag to deal with join subflows
Date: Fri, 15 May 2020 11:29:32 -0700 [thread overview]
Message-ID: <20200515182932.GA45434@MacBook-Pro-64.local> (raw)
In-Reply-To: a5acf97e4f39de13ba178a3a007eedd83b418702.1589558049.git.pabeni@redhat.com
[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]
On 15/05/20 - 19:22:15, Paolo Abeni wrote:
> MP_JOIN subflows must not land into the accept queue.
> Currently tcp_check_req() calls an mptcp specific helper
> to detect such scenario.
>
> Such helper leverages the subflow context to check for
> MP_JOIN subflows. We need to deal also with MP JOIN
> failures, even when the subflow context is not available
> due allocation failure.
>
> A possible solution would be changing the syn_recv_sock()
> signature to allow returning a more descriptive action/
> error code and deal with that in tcp_check_req().
>
> Since the above need is MPTCP specific, this patch instead
> uses a TCP request socket hole to add a MPTCP specific flag.
> Such flag is used by the MPTCP syn_recv_sock() to tell
> tcp_check_req() how to deal with the request socket.
>
> This change is a no-op for !MPTCP build, and makes the
> MPTCP code simpler. It allows also the next patch to deal
> correctly with MP JOIN failure.
>
> v1 -> v2:
> - be more conservative on drop_req initialization (Mat)
>
> RFC -> v1:
> - move the drop_req bit inside tcp_request_sock (Eric)
>
> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
> ---
> include/linux/tcp.h | 3 +++
> include/net/mptcp.h | 17 ++++++++++-------
> net/ipv4/tcp_minisocks.c | 2 +-
> net/mptcp/protocol.c | 7 -------
> net/mptcp/subflow.c | 3 +++
> 5 files changed, 17 insertions(+), 15 deletions(-)
Reviewed-by: Christoph Paasch <cpaasch(a)apple.com>
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Paasch <cpaasch@apple.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
"David S . Miller" <davem@davemloft.net>,
mptcp@lists.01.org,
Mat Martineau <mathew.j.martineau@linux.intel.com>
Subject: Re: [PATCH net-next v2 1/3] mptcp: add new sock flag to deal with join subflows
Date: Fri, 15 May 2020 11:29:32 -0700 [thread overview]
Message-ID: <20200515182932.GA45434@MacBook-Pro-64.local> (raw)
In-Reply-To: <a5acf97e4f39de13ba178a3a007eedd83b418702.1589558049.git.pabeni@redhat.com>
On 15/05/20 - 19:22:15, Paolo Abeni wrote:
> MP_JOIN subflows must not land into the accept queue.
> Currently tcp_check_req() calls an mptcp specific helper
> to detect such scenario.
>
> Such helper leverages the subflow context to check for
> MP_JOIN subflows. We need to deal also with MP JOIN
> failures, even when the subflow context is not available
> due allocation failure.
>
> A possible solution would be changing the syn_recv_sock()
> signature to allow returning a more descriptive action/
> error code and deal with that in tcp_check_req().
>
> Since the above need is MPTCP specific, this patch instead
> uses a TCP request socket hole to add a MPTCP specific flag.
> Such flag is used by the MPTCP syn_recv_sock() to tell
> tcp_check_req() how to deal with the request socket.
>
> This change is a no-op for !MPTCP build, and makes the
> MPTCP code simpler. It allows also the next patch to deal
> correctly with MP JOIN failure.
>
> v1 -> v2:
> - be more conservative on drop_req initialization (Mat)
>
> RFC -> v1:
> - move the drop_req bit inside tcp_request_sock (Eric)
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> include/linux/tcp.h | 3 +++
> include/net/mptcp.h | 17 ++++++++++-------
> net/ipv4/tcp_minisocks.c | 2 +-
> net/mptcp/protocol.c | 7 -------
> net/mptcp/subflow.c | 3 +++
> 5 files changed, 17 insertions(+), 15 deletions(-)
Reviewed-by: Christoph Paasch <cpaasch@apple.com>
next reply other threads:[~2020-05-15 18:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 18:29 Christoph Paasch [this message]
2020-05-15 18:29 ` [PATCH net-next v2 1/3] mptcp: add new sock flag to deal with join subflows Christoph Paasch
-- strict thread matches above, loose matches on Subject: below --
2020-05-15 19:30 [MPTCP] Re: [PATCH net-next v2 0/3] mptcp: fix MP_JOIN failure handling David Miller
2020-05-15 19:30 ` David Miller
2020-05-15 18:10 [MPTCP] Re: [PATCH net-next v2 3/3] mptcp: cope better with MP_JOIN failure Mat Martineau
2020-05-15 18:10 ` Mat Martineau
2020-05-15 18:09 [MPTCP] Re: [PATCH net-next v2 2/3] inet_connection_sock: factor out destroy helper Mat Martineau
2020-05-15 18:09 ` Mat Martineau
2020-05-15 18:09 [MPTCP] Re: [PATCH net-next v2 1/3] mptcp: add new sock flag to deal with join subflows Mat Martineau
2020-05-15 18:09 ` Mat Martineau
2020-05-15 17:22 [MPTCP] [PATCH net-next v2 3/3] mptcp: cope better with MP_JOIN failure Paolo Abeni
2020-05-15 17:22 ` Paolo Abeni
2020-05-15 17:22 [MPTCP] [PATCH net-next v2 2/3] inet_connection_sock: factor out destroy helper Paolo Abeni
2020-05-15 17:22 ` Paolo Abeni
2020-05-15 17:22 [MPTCP] [PATCH net-next v2 1/3] mptcp: add new sock flag to deal with join subflows Paolo Abeni
2020-05-15 17:22 ` Paolo Abeni
2020-05-15 17:22 [MPTCP] [PATCH net-next v2 0/3] mptcp: fix MP_JOIN failure handling Paolo Abeni
2020-05-15 17:22 ` Paolo Abeni
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=20200515182932.GA45434@MacBook-Pro-64.local \
--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.