netdev - Re: [PATCH bpf-next v2] selftests/bpf: Fix spurious failures in accept due to EAGAIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4Bza493cXh+ffS7KHtgGnVDYwyxwDXQ_G6Ps1Bfm4WVRLQA@mail.gmail.com>
Date:   Fri, 13 Mar 2020 12:01:43 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Jakub Sitnicki <jakub@...udflare.com>,
        Stanislav Fomichev <sdf@...gle.com>
Cc:     bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        kernel-team@...udflare.com
Subject: Re: [PATCH bpf-next v2] selftests/bpf: Fix spurious failures in
 accept due to EAGAIN

On Fri, Mar 13, 2020 at 9:10 AM Jakub Sitnicki <jakub@...udflare.com> wrote:
>
> Andrii Nakryiko reports that sockmap_listen test suite is frequently
> failing due to accept() calls erroring out with EAGAIN:
>
>   ./test_progs:connect_accept_thread:733: accept: Resource temporarily unavailable
>   connect_accept_thread:FAIL:733
>
> This is because we are using a non-blocking listening TCP socket to
> accept() connections without polling on the socket.
>
> While at first switching to blocking mode seems like the right thing to do,
> this could lead to test process blocking indefinitely in face of a network
> issue, like loopback interface being down, as Andrii pointed out.
>
> Hence, stick to non-blocking mode for TCP listening sockets but with
> polling for incoming connection for a limited time before giving up.
>
> Apply this approach to all socket I/O calls in the test suite that we
> expect to block indefinitely, that is accept() for TCP and recv() for UDP.
>
> Fixes: 44d28be2b8d4 ("selftests/bpf: Tests for sockmap/sockhash holding listening sockets")
> Reported-by: Andrii Nakryiko <andrii.nakryiko@...il.com>
> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>
> ---

This looks good. Unfortunately can't repro the issue locally anymore.
But once this gets into bpf-next and we update libbpf in Github, I'll
enable sockmap_listen tests again and see if it's still flaky. Thanks
for following up!

Stanislav, would you get a chance to do something similar for tcp_rtt
as well? Seems like all the tests dealing with sockets might use this
approach?

Acked-by: Andrii Nakryiko <andriin@...com>

>
> Notes:
>     v2: Switch back to non-blocking mode, but with polling and timeout.
>         Extend the fix to all I/O calls that we expect to block. (Andrii)
>
>  .../selftests/bpf/prog_tests/sockmap_listen.c | 77 ++++++++++++++-----
>  1 file changed, 58 insertions(+), 19 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
> index 52aa468bdccd..d7d65a700799 100644
> --- a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
> +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
> @@ -16,6 +16,7 @@

[...]