From: Jakub Sitnicki <jakub@cloudflare.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
daniel@iogearbox.net, joamaki@gmail.com,
xiyou.wangcong@gmail.com
Subject: Re: [PATCH bpf 1/4] bpf, sockmap: Remove unhash handler for BPF sockmap usage
Date: Tue, 19 Oct 2021 09:17:23 +0200 [thread overview]
Message-ID: <87tuhdfpq4.fsf@cloudflare.com> (raw)
In-Reply-To: <20211011191647.418704-2-john.fastabend@gmail.com>
On Mon, Oct 11, 2021 at 09:16 PM CEST, John Fastabend wrote:
> 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>
> ---
Doesn't this open the possibility of having a TCP_CLOSE socket in
sockmap if I disconnect it, that is call connect(AF_UNSPEC), instead of
close it?
next prev parent reply other threads:[~2021-10-19 7: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 ` [PATCH bpf 1/4] bpf, sockmap: Remove unhash handler for BPF sockmap usage John Fastabend
2021-10-19 7:17 ` Jakub Sitnicki [this message]
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=87tuhdfpq4.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=joamaki@gmail.com \
--cc=john.fastabend@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).