Re: [PATCH bpf-next v5 12/12] selftests/bpf: Tests for SOCKMAP holding listening sockets

On Wed, Mar 11, 2020 at 10:02 PM CET, Andrii Nakryiko wrote:

On Wed, Mar 11, 2020 at 12:49 PM Jakub Sitnicki [off-list ref] wrote:

quoted

On Wed, Mar 11, 2020 at 07:48 PM CET, Andrii Nakryiko wrote:

quoted

On Mon, Jan 27, 2020 at 4:58 AM Jakub Sitnicki [off-list ref] wrote:

quoted

Now that SOCKMAP can store listening sockets, user-space and BPF API is
open to a new set of potential pitfalls. Exercise the map operations (with
extra attention to code paths susceptible to races between map ops and
socket cloning), and BPF helpers that work with SOCKMAP to gain confidence
that all works as expected.

Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
---
 .../selftests/bpf/prog_tests/sockmap_listen.c | 1455 +++++++++++++++++
 .../selftests/bpf/progs/test_sockmap_listen.c |   77 +
 2 files changed, 1532 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_sockmap_listen.c

Hey Jakub!

I'm frequently getting spurious failures for sockmap_listen selftest.
We also see that in libbpf's Github CI testing as well. Do you mind
taking a look? Usually it's the following kinds of error:

./test_progs:connect_accept_thread:733: accept: Resource temporarily unavailable
connect_accept_thread:FAIL:733

Hey Andrii,

Sorry about that. Will investigate why this is happening.

Can't say I've seen those. Any additional details about the test
enviroment would be helpful. Like the kernel build config and qemu
params (e.g. 1 vCPU vs more).

It happens quite regularly for me, once every few runs locally. You
can take a kernel config we use for Travis CI at [0].

  [0] https://github.com/libbpf/libbpf/blob/master/travis-ci/vmtest/configs/latest.config

Reproduced it. This should help:

  https://lore.kernel.org/bpf/20200312171105.533690-1-jakub@cloudflare.com/T/#u (local)

Thanks for bringing it to my attention.

[...]