bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: bpf@vger.kernel.org, netdev@vger.kernel.org
Cc: john.fastabend@gmail.com, daniel@iogearbox.net,
	joamaki@gmail.com, xiyou.wangcong@gmail.com
Subject: [PATCH bpf 1/4] bpf, sockmap: Remove unhash handler for BPF sockmap usage
Date: Mon, 11 Oct 2021 12:16:44 -0700	[thread overview]
Message-ID: <20211011191647.418704-2-john.fastabend@gmail.com> (raw)
In-Reply-To: <20211011191647.418704-1-john.fastabend@gmail.com>

We do not need to handle unhash from BPF side we can simply wait for the
close to happen. The original concern was a socket could transition from
ESTABLISHED state to a new state while the BPF hook was still attached.
But, we convinced ourself this is no longer possible and we also
improved BPF sockmap to handle listen sockets so this is no longer a
problem.

More importantly though there are cases where unhash is called when data is
in the receive queue. The BPF unhash logic will flush this data which is
wrong. To be correct it should keep the data in the receive queue and allow
a receiving application to continue reading the data. This may happen when
tcp_abort is received for example. Instead of complicating the logic in
unhash simply moving all this to tcp_close hook solves this.

Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
 net/ipv4/tcp_bpf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index d3e9386b493e..35dcfb04f53d 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -476,7 +476,6 @@ static void tcp_bpf_rebuild_protos(struct proto prot[TCP_BPF_NUM_CFGS],
 				   struct proto *base)
 {
 	prot[TCP_BPF_BASE]			= *base;
-	prot[TCP_BPF_BASE].unhash		= sock_map_unhash;
 	prot[TCP_BPF_BASE].close		= sock_map_close;
 	prot[TCP_BPF_BASE].recvmsg		= tcp_bpf_recvmsg;
 	prot[TCP_BPF_BASE].stream_memory_read	= tcp_bpf_stream_read;
-- 
2.33.0


  reply	other threads:[~2021-10-11 19:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 19:16 [PATCH bpf 0/4] bpf, sockmap: fixes stress testing and regression John Fastabend
2021-10-11 19:16 ` John Fastabend [this message]
2021-10-19  7:17   ` [PATCH bpf 1/4] bpf, sockmap: Remove unhash handler for BPF sockmap usage Jakub Sitnicki
2021-10-20  5:28     ` John Fastabend
2021-10-20 15:11       ` Jakub Sitnicki
2021-10-20 15:51         ` John Fastabend
2021-10-20 16:35           ` Jakub Sitnicki
2021-10-21 19:24             ` John Fastabend
2021-10-11 19:16 ` [PATCH bpf 2/4] bpf, sockmap: Fix race in ingress receive verdict with redirect to self John Fastabend
2021-10-19  9:16   ` Jakub Sitnicki
2021-10-11 19:16 ` [PATCH bpf 3/4] bpf: sockmap, strparser, and tls are reusing qdisc_skb_cb and colliding John Fastabend
2021-10-19 15:39   ` Jakub Sitnicki
2021-10-11 19:16 ` [PATCH bpf 4/4] bpf, sockmap: sk_skb data_end access incorrect when src_reg = dst_reg John Fastabend
2021-10-23 13:05   ` Jakub Sitnicki

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=20211011191647.418704-2-john.fastabend@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=joamaki@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.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 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).