All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@fomichev.me>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Stanislav Fomichev <sdf@google.com>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH bpf] selftests/bpf: test_progs: fix client/server race in tcp_rtt
Date: Mon, 23 Sep 2019 08:38:19 -0700	[thread overview]
Message-ID: <20190923153819.GA21441@mini-arch> (raw)
In-Reply-To: <CAEf4BzYFQhPKoDG7kq=_B5caL-0Af2duL_Uz5v3oVw=BKQ430w@mail.gmail.com>

On 09/22, Andrii Nakryiko wrote:
> On Sun, Sep 22, 2019 at 12:10 PM Stanislav Fomichev <sdf@google.com> wrote:
> >
> > This is the same problem I found earlier in test_sockopt_inherit:
> > there is a race between server thread doing accept() and client
> > thread doing connect(). Let's explicitly synchronize them via
> > pthread conditional variable.
> >
> > Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> >  tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > index fdc0b3614a9e..e64058906bcd 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > @@ -203,6 +203,9 @@ static int start_server(void)
> >         return fd;
> >  }
> >
> > +static pthread_mutex_t server_started_mtx = PTHREAD_MUTEX_INITIALIZER;
> > +static pthread_cond_t server_started = PTHREAD_COND_INITIALIZER;
> > +
> >  static void *server_thread(void *arg)
> >  {
> >         struct sockaddr_storage addr;
> > @@ -215,6 +218,10 @@ static void *server_thread(void *arg)
> >                 return NULL;
> >         }
> >
> > +       pthread_mutex_lock(&server_started_mtx);
> > +       pthread_cond_signal(&server_started);
> > +       pthread_mutex_unlock(&server_started_mtx);
> > +
> >         client_fd = accept(fd, (struct sockaddr *)&addr, &len);
> >         if (CHECK_FAIL(client_fd < 0)) {
> >                 perror("Failed to accept client");
> > @@ -248,7 +255,14 @@ void test_tcp_rtt(void)
> >         if (CHECK_FAIL(server_fd < 0))
> >                 goto close_cgroup_fd;
> >
> > -       pthread_create(&tid, NULL, server_thread, (void *)&server_fd);
> > +       if (CHECK_FAIL(pthread_create(&tid, NULL, server_thread,
> > +                                     (void *)&server_fd)))
> > +               goto close_cgroup_fd;
> > +
> > +       pthread_mutex_lock(&server_started_mtx);
> > +       pthread_cond_wait(&server_started, &server_started_mtx);
> > +       pthread_mutex_unlock(&server_started_mtx);
> 
> 
> If the server fails to listen, then we'll never get a signal, right?
> Let's use timedwait instead to avoid test getting stuck forever in
> such cases?
Good point. How about I do the same thing I do in sockopt_inherit tests:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c#n73

	err = listen()
	pthread_cond_signal()
	if (CHECK_FAIL(err)) {
		return;
	}

Should fix the problem of getting stuck forever without any timeouts.
I'll send a v2 later today.

> > +
> >         CHECK_FAIL(run_test(cgroup_fd, server_fd));
> >         close(server_fd);
> >  close_cgroup_fd:
> > --
> > 2.23.0.351.gc4317032e6-goog
> >

  reply	other threads:[~2019-09-23 15:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20 23:30 [PATCH bpf] selftests/bpf: test_progs: fix client/server race in tcp_rtt Stanislav Fomichev
2019-09-22 21:03 ` Andrii Nakryiko
2019-09-23 15:38   ` Stanislav Fomichev [this message]
2019-09-23 16:41     ` Andrii Nakryiko

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=20190923153819.GA21441@mini-arch \
    --to=sdf@fomichev.me \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.