* [PATCH bpf] bpf: tcp: recv() should return 0 when the peer socket is closed
@ 2020-06-10 10:19 Sabrina Dubroca
2020-06-12 10:15 ` Jakub Sitnicki
0 siblings, 1 reply; 4+ messages in thread
From: Sabrina Dubroca @ 2020-06-10 10:19 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, John Fastabend, Daniel Borkmann, bpf
If the peer is closed, we will never get more data, so
tcp_bpf_wait_data will get stuck forever. In case we passed
MSG_DONTWAIT to recv(), we get EAGAIN but we should actually get
0.
From man 2 recv:
RETURN VALUE
When a stream socket peer has performed an orderly shutdown, the
return value will be 0 (the traditional "end-of-file" return).
This patch makes tcp_bpf_wait_data always return 1 when the peer
socket has been shutdown. Either we have data available, and it would
have returned 1 anyway, or there isn't, in which case we'll call
tcp_recvmsg which does the right thing in this situation.
Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
net/ipv4/tcp_bpf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index 2b915aafda42..7aa68f4aae6c 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -245,6 +245,9 @@ static int tcp_bpf_wait_data(struct sock *sk, struct sk_psock *psock,
DEFINE_WAIT_FUNC(wait, woken_wake_function);
int ret = 0;
+ if (sk->sk_shutdown & RCV_SHUTDOWN)
+ return 1;
+
if (!timeo)
return ret;
--
2.27.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH bpf] bpf: tcp: recv() should return 0 when the peer socket is closed
2020-06-10 10:19 [PATCH bpf] bpf: tcp: recv() should return 0 when the peer socket is closed Sabrina Dubroca
@ 2020-06-12 10:15 ` Jakub Sitnicki
2020-06-12 22:13 ` Alexei Starovoitov
0 siblings, 1 reply; 4+ messages in thread
From: Jakub Sitnicki @ 2020-06-12 10:15 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev, John Fastabend, Daniel Borkmann, bpf
On Wed, 10 Jun 2020 12:19:43 +0200
Sabrina Dubroca <sd@queasysnail.net> wrote:
> If the peer is closed, we will never get more data, so
> tcp_bpf_wait_data will get stuck forever. In case we passed
> MSG_DONTWAIT to recv(), we get EAGAIN but we should actually get
> 0.
>
> From man 2 recv:
>
> RETURN VALUE
>
> When a stream socket peer has performed an orderly shutdown, the
> return value will be 0 (the traditional "end-of-file" return).
>
> This patch makes tcp_bpf_wait_data always return 1 when the peer
> socket has been shutdown. Either we have data available, and it would
> have returned 1 anyway, or there isn't, in which case we'll call
> tcp_recvmsg which does the right thing in this situation.
>
> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> ---
> net/ipv4/tcp_bpf.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
> index 2b915aafda42..7aa68f4aae6c 100644
> --- a/net/ipv4/tcp_bpf.c
> +++ b/net/ipv4/tcp_bpf.c
> @@ -245,6 +245,9 @@ static int tcp_bpf_wait_data(struct sock *sk, struct sk_psock *psock,
> DEFINE_WAIT_FUNC(wait, woken_wake_function);
> int ret = 0;
>
> + if (sk->sk_shutdown & RCV_SHUTDOWN)
> + return 1;
> +
> if (!timeo)
> return ret;
>
Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH bpf] bpf: tcp: recv() should return 0 when the peer socket is closed
2020-06-12 10:15 ` Jakub Sitnicki
@ 2020-06-12 22:13 ` Alexei Starovoitov
2020-06-12 22:52 ` John Fastabend
0 siblings, 1 reply; 4+ messages in thread
From: Alexei Starovoitov @ 2020-06-12 22:13 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Sabrina Dubroca, Network Development, John Fastabend,
Daniel Borkmann, bpf
On Fri, Jun 12, 2020 at 3:18 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
> On Wed, 10 Jun 2020 12:19:43 +0200
> Sabrina Dubroca <sd@queasysnail.net> wrote:
>
> > If the peer is closed, we will never get more data, so
> > tcp_bpf_wait_data will get stuck forever. In case we passed
> > MSG_DONTWAIT to recv(), we get EAGAIN but we should actually get
> > 0.
> >
> > From man 2 recv:
> >
> > RETURN VALUE
> >
> > When a stream socket peer has performed an orderly shutdown, the
> > return value will be 0 (the traditional "end-of-file" return).
> >
> > This patch makes tcp_bpf_wait_data always return 1 when the peer
> > socket has been shutdown. Either we have data available, and it would
> > have returned 1 anyway, or there isn't, in which case we'll call
> > tcp_recvmsg which does the right thing in this situation.
> >
> > Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > ---
> > net/ipv4/tcp_bpf.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
> > index 2b915aafda42..7aa68f4aae6c 100644
> > --- a/net/ipv4/tcp_bpf.c
> > +++ b/net/ipv4/tcp_bpf.c
> > @@ -245,6 +245,9 @@ static int tcp_bpf_wait_data(struct sock *sk, struct sk_psock *psock,
> > DEFINE_WAIT_FUNC(wait, woken_wake_function);
> > int ret = 0;
> >
> > + if (sk->sk_shutdown & RCV_SHUTDOWN)
> > + return 1;
> > +
> > if (!timeo)
> > return ret;
> >
>
> Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
Applied. Thanks
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH bpf] bpf: tcp: recv() should return 0 when the peer socket is closed
2020-06-12 22:13 ` Alexei Starovoitov
@ 2020-06-12 22:52 ` John Fastabend
0 siblings, 0 replies; 4+ messages in thread
From: John Fastabend @ 2020-06-12 22:52 UTC (permalink / raw)
To: Alexei Starovoitov, Jakub Sitnicki
Cc: Sabrina Dubroca, Network Development, John Fastabend,
Daniel Borkmann, bpf
Alexei Starovoitov wrote:
> On Fri, Jun 12, 2020 at 3:18 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >
> > On Wed, 10 Jun 2020 12:19:43 +0200
> > Sabrina Dubroca <sd@queasysnail.net> wrote:
> >
> > > If the peer is closed, we will never get more data, so
> > > tcp_bpf_wait_data will get stuck forever. In case we passed
> > > MSG_DONTWAIT to recv(), we get EAGAIN but we should actually get
> > > 0.
> > >
> > > From man 2 recv:
> > >
> > > RETURN VALUE
> > >
> > > When a stream socket peer has performed an orderly shutdown, the
> > > return value will be 0 (the traditional "end-of-file" return).
> > >
> > > This patch makes tcp_bpf_wait_data always return 1 when the peer
> > > socket has been shutdown. Either we have data available, and it would
> > > have returned 1 anyway, or there isn't, in which case we'll call
> > > tcp_recvmsg which does the right thing in this situation.
> > >
> > > Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
> > > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > > ---
> > > net/ipv4/tcp_bpf.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
> > > index 2b915aafda42..7aa68f4aae6c 100644
> > > --- a/net/ipv4/tcp_bpf.c
> > > +++ b/net/ipv4/tcp_bpf.c
> > > @@ -245,6 +245,9 @@ static int tcp_bpf_wait_data(struct sock *sk, struct sk_psock *psock,
> > > DEFINE_WAIT_FUNC(wait, woken_wake_function);
> > > int ret = 0;
> > >
> > > + if (sk->sk_shutdown & RCV_SHUTDOWN)
> > > + return 1;
> > > +
> > > if (!timeo)
> > > return ret;
> > >
> >
> > Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
>
> Applied. Thanks
Thanks for the patch. LGTM, I guess we should also break the
copy loop in __tcp_bpf_recvmsg if RCV_SHUTDOWN is set it
looks like TCP stack does. I'll send a follow up thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-06-12 22:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-10 10:19 [PATCH bpf] bpf: tcp: recv() should return 0 when the peer socket is closed Sabrina Dubroca
2020-06-12 10:15 ` Jakub Sitnicki
2020-06-12 22:13 ` Alexei Starovoitov
2020-06-12 22:52 ` John Fastabend
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).