All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net] tcp: allow MSG_ZEROCOPY transmission also in CLOSE_WAIT state
@ 2019-01-10 19:40 Willem de Bruijn
  2019-01-10 19:45 ` Soheil Hassas Yeganeh
  2019-01-16  5:44 ` David Miller
  0 siblings, 2 replies; 4+ messages in thread
From: Willem de Bruijn @ 2019-01-10 19:40 UTC (permalink / raw)
  To: netdev
  Cc: davem, edumazet, Willem de Bruijn, Marek Majkowski,
	Yuchung Cheng, Neal Cardwell, Soheil Hassas Yeganeh,
	Alexey Kodanev

From: Willem de Bruijn <willemb@google.com>

TCP transmission with MSG_ZEROCOPY fails if the peer closes its end of
the connection and so transitions this socket to CLOSE_WAIT state.

Transmission in close wait state is acceptable. Other similar tests in
the stack (e.g., in FastOpen) accept both states. Relax this test, too.

Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg276886.html
Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg227390.html
Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
Reported-by: Marek Majkowski <marek@cloudflare.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
CC: Yuchung Cheng <ycheng@google.com>
CC: Neal Cardwell <ncardwell@google.com>
CC: Soheil Hassas Yeganeh <soheil@google.com>
CC: Alexey Kodanev <alexey.kodanev@oracle.com>
---

This is a narrow fix. Alexey Kodanev suggested a while ago that the
entire check might be removed, also opening up more cases for zerocopy
with fastopen. For net-next, I will take another look at that and also
at adding a tcp_data_sending_states() helper to avoid open coding this
test everywhere.
---
 net/ipv4/tcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 27e2f6837062..2079145a3b7c 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1186,7 +1186,7 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
 	flags = msg->msg_flags;
 
 	if (flags & MSG_ZEROCOPY && size && sock_flag(sk, SOCK_ZEROCOPY)) {
-		if (sk->sk_state != TCP_ESTABLISHED) {
+		if ((1 << sk->sk_state) & ~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) {
 			err = -EINVAL;
 			goto out_err;
 		}
-- 
2.20.1.97.g81188d93c3-goog

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH net] tcp: allow MSG_ZEROCOPY transmission also in CLOSE_WAIT state
  2019-01-10 19:40 [PATCH net] tcp: allow MSG_ZEROCOPY transmission also in CLOSE_WAIT state Willem de Bruijn
@ 2019-01-10 19:45 ` Soheil Hassas Yeganeh
  2019-01-11 10:45   ` Eric Dumazet
  2019-01-16  5:44 ` David Miller
  1 sibling, 1 reply; 4+ messages in thread
From: Soheil Hassas Yeganeh @ 2019-01-10 19:45 UTC (permalink / raw)
  To: Willem de Bruijn
  Cc: netdev, David Miller, Eric Dumazet, Willem de Bruijn,
	Marek Majkowski, Yuchung Cheng, Neal Cardwell, Alexey Kodanev

On Thu, Jan 10, 2019 at 2:40 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> From: Willem de Bruijn <willemb@google.com>
>
> TCP transmission with MSG_ZEROCOPY fails if the peer closes its end of
> the connection and so transitions this socket to CLOSE_WAIT state.
>
> Transmission in close wait state is acceptable. Other similar tests in
> the stack (e.g., in FastOpen) accept both states. Relax this test, too.
>
> Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg276886.html
> Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg227390.html
> Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
> Reported-by: Marek Majkowski <marek@cloudflare.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> CC: Yuchung Cheng <ycheng@google.com>
> CC: Neal Cardwell <ncardwell@google.com>
> CC: Soheil Hassas Yeganeh <soheil@google.com>
> CC: Alexey Kodanev <alexey.kodanev@oracle.com>

Acked-by: Soheil Hassas Yeganeh <soheil@google.com>

Thank you for the fix!

> ---
>
> This is a narrow fix. Alexey Kodanev suggested a while ago that the
> entire check might be removed, also opening up more cases for zerocopy
> with fastopen. For net-next, I will take another look at that and also
> at adding a tcp_data_sending_states() helper to avoid open coding this
> test everywhere.
> ---
>  net/ipv4/tcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 27e2f6837062..2079145a3b7c 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1186,7 +1186,7 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
>         flags = msg->msg_flags;
>
>         if (flags & MSG_ZEROCOPY && size && sock_flag(sk, SOCK_ZEROCOPY)) {
> -               if (sk->sk_state != TCP_ESTABLISHED) {
> +               if ((1 << sk->sk_state) & ~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) {
>                         err = -EINVAL;
>                         goto out_err;
>                 }
> --
> 2.20.1.97.g81188d93c3-goog
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net] tcp: allow MSG_ZEROCOPY transmission also in CLOSE_WAIT state
  2019-01-10 19:45 ` Soheil Hassas Yeganeh
@ 2019-01-11 10:45   ` Eric Dumazet
  0 siblings, 0 replies; 4+ messages in thread
From: Eric Dumazet @ 2019-01-11 10:45 UTC (permalink / raw)
  To: Soheil Hassas Yeganeh, Willem de Bruijn
  Cc: netdev, David Miller, Eric Dumazet, Willem de Bruijn,
	Marek Majkowski, Yuchung Cheng, Neal Cardwell, Alexey Kodanev



On 01/10/2019 11:45 AM, Soheil Hassas Yeganeh wrote:
> On Thu, Jan 10, 2019 at 2:40 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>>
>> From: Willem de Bruijn <willemb@google.com>
>>
>> TCP transmission with MSG_ZEROCOPY fails if the peer closes its end of
>> the connection and so transitions this socket to CLOSE_WAIT state.
>>
>> Transmission in close wait state is acceptable. Other similar tests in
>> the stack (e.g., in FastOpen) accept both states. Relax this test, too.
>>
>> Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg276886.html
>> Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg227390.html
>> Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
>> Reported-by: Marek Majkowski <marek@cloudflare.com>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>> CC: Yuchung Cheng <ycheng@google.com>
>> CC: Neal Cardwell <ncardwell@google.com>
>> CC: Soheil Hassas Yeganeh <soheil@google.com>
>> CC: Alexey Kodanev <alexey.kodanev@oracle.com>
> 
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> 
> Thank you for the fix!

Reviewed-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net] tcp: allow MSG_ZEROCOPY transmission also in CLOSE_WAIT state
  2019-01-10 19:40 [PATCH net] tcp: allow MSG_ZEROCOPY transmission also in CLOSE_WAIT state Willem de Bruijn
  2019-01-10 19:45 ` Soheil Hassas Yeganeh
@ 2019-01-16  5:44 ` David Miller
  1 sibling, 0 replies; 4+ messages in thread
From: David Miller @ 2019-01-16  5:44 UTC (permalink / raw)
  To: willemdebruijn.kernel
  Cc: netdev, edumazet, willemb, marek, ycheng, ncardwell, soheil,
	alexey.kodanev

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Thu, 10 Jan 2019 14:40:33 -0500

> From: Willem de Bruijn <willemb@google.com>
> 
> TCP transmission with MSG_ZEROCOPY fails if the peer closes its end of
> the connection and so transitions this socket to CLOSE_WAIT state.
> 
> Transmission in close wait state is acceptable. Other similar tests in
> the stack (e.g., in FastOpen) accept both states. Relax this test, too.
> 
> Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg276886.html
> Link: https://www.mail-archive.com/netdev@vger.kernel.org/msg227390.html
> Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
> Reported-by: Marek Majkowski <marek@cloudflare.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>

Applied and queued up for -stable.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-01-16  5:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-10 19:40 [PATCH net] tcp: allow MSG_ZEROCOPY transmission also in CLOSE_WAIT state Willem de Bruijn
2019-01-10 19:45 ` Soheil Hassas Yeganeh
2019-01-11 10:45   ` Eric Dumazet
2019-01-16  5:44 ` David Miller

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.