[PATCH bpf-next 0/3] Sockmap iterator

[Lorenz Bauer <lmb@cloudflare.com>]

Add a new bpf_iter for sockmap and sockhash. As previously discussed, we
want to use this to copy a sockhash in kernel space while modifying the
format of the keys.

The implementation leans heavily on the existing bpf_sk_storage and
hashtable iterators. However, there is a key difference for the sockmap
iterator: we don't take any bucket locks during iteration. It seems to
me that there is a risk of deadlock here if the iterator attempts to
insert an item into the bucket that we are currently iterating. I think
that the semantics are reasonable even without the lock.

In the iteration context I expose a PTR_TO_SOCKET_OR_NULL, aka struct
bpf_sock*. This is in contrast to bpf_sk_storage which uses a
PTR_TO_BTF_ID_OR_NULL, aka struct sock*. My personal preference would
be to use PTR_TO_BTF_ID_OR_NULL for sockmap as well, however the
verifier currently doesn't understand that PTR_TO_BTF_ID for struct
sock can be coerced to PTR_TO_SOCKET_OR_NULL. So we can't call
map_update_elem, etc. and the whole exercise is for naught. I'm
considering teaching this trick to the verifier, does anyone have
concerns or ideas how to achieve this?

Thanks to Yonghong for guidance on how to go about this, and for
adding bpf_iter in the first place!

Lorenz Bauer (3):
  net: Allow iterating sockmap and sockhash
  selftests: bpf: Add helper to compare socket cookies
  selftests: bpf: Test copying a sockmap via bpf_iter

 net/core/sock_map.c                           | 283 ++++++++++++++++++
 .../selftests/bpf/prog_tests/sockmap_basic.c  | 129 +++++++-
 tools/testing/selftests/bpf/progs/bpf_iter.h  |   9 +
 .../selftests/bpf/progs/bpf_iter_sockmap.c    |  50 ++++
 4 files changed, 457 insertions(+), 14 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_sockmap.c

-- 
2.25.1