summaryrefslogtreecommitdiff
path: root/scripts/bpf_helpers_doc.py
diff options
context:
space:
mode:
authorJakub Sitnicki <jakub@cloudflare.com>2020-02-17 12:15:30 +0000
committerDaniel Borkmann <daniel@iogearbox.net>2020-02-19 16:54:05 +0100
commitd1ba1204f2eec134937cb32997ee47756d448aa2 (patch)
tree20be453de9bbad27e82af5f26490e642ccda7437 /scripts/bpf_helpers_doc.py
parenta178b4585865a4c756c41bc5376f63416b7d9271 (diff)
selftests/bpf: Test unhashing kTLS socket after removing from map
When a TCP socket gets inserted into a sockmap, its sk_prot callbacks get replaced with tcp_bpf callbacks built from regular tcp callbacks. If TLS gets enabled on the same socket, sk_prot callbacks get replaced once again, this time with kTLS callbacks built from tcp_bpf callbacks. Now, we allow removing a socket from a sockmap that has kTLS enabled. After removal, socket remains with kTLS configured. This is where things things get tricky. Since the socket has a set of sk_prot callbacks that are a mix of kTLS and tcp_bpf callbacks, we need to restore just the tcp_bpf callbacks to the original ones. At the moment, it comes down to the the unhash operation. We had a regression recently because tcp_bpf callbacks were not cleared in this particular scenario of removing a kTLS socket from a sockmap. It got fixed in commit 4da6a196f93b ("bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop"). Add a test that triggers the regression so that we don't reintroduce it in the future. Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20200217121530.754315-4-jakub@cloudflare.com
Diffstat (limited to 'scripts/bpf_helpers_doc.py')
0 files changed, 0 insertions, 0 deletions