All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Cong Wang <cong.wang@bytedance.com>,
	Jiang Wang <jiang.wang@bytedance.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jakub Sitnicki <jakub@cloudflare.com>,
	Lorenz Bauer <lmb@cloudflare.com>
Subject: Re: [Patch bpf] selftests/bpf: Retry for EAGAIN in udp_redir_to_connected()
Date: Thu, 20 May 2021 22:12:25 -0700	[thread overview]
Message-ID: <CAEf4BzYUw8bTUXEdrkRwqFg0OGsMTNe+kwxkbdqAMV9we4xifw@mail.gmail.com> (raw)
In-Reply-To: <CAM_iQpVAhOOP_PRsvL37J1WwOxHKmLEnRXVBYag1nNccHN7PYw@mail.gmail.com>

On Thu, May 20, 2021 at 1:44 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Thu, May 20, 2021 at 1:14 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > Bugs do happen though, so if you can detect some error condition
> > instead of having an infinite loop, then do it.
>
> You both are underestimating the problem. There are two different things
> to consider here:
>
> 1) Kernel bugs: This is known unknown, we certainly do not know
> how many bugs we have, otherwise they would have been fixed
> already. So we can not predict the consequence of the bug either,
> assuming a bug could only cause packet drop is underestimated.
>
> 2) Configurations: For instance, firewall rules. If the selftests are run
> in a weird firewall setup which drops all UDP packets, there is nothing
> we can do in the test itself. If we have to detect this, then we would
> have to detect netem cases too where packets can be held indefinitely
> or reordered arbitrarily. The possibilities here are too many to detect,
> hence I argue the selftests should setup its own non-hostile environment,
> which has nothing to do with any specific program.
>
> This is why I ask you to draw a boundary: what we can assume and
> what we can't. My boundary is obviously clear: we just assume the
> environment is non-hostile and we can't predict any kernel bugs,
> nor their consequences.

It doesn't matter. Instead of having an endless loop, please add a
counter and limit the number of iterations to some reasonable number.
That's all, no one is asking you to do something impossible, just
prevent looping forever in some unforeseen situations and just fail
the test instead.

>
> Thanks.

  reply	other threads:[~2021-05-21  5:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19 20:41 [Patch bpf] selftests/bpf: Retry for EAGAIN in udp_redir_to_connected() Cong Wang
2021-05-19 21:55 ` John Fastabend
2021-05-19 23:36   ` Cong Wang
2021-05-20 17:47     ` John Fastabend
2021-05-20 20:00       ` Cong Wang
2021-05-22  0:12         ` Andrii Nakryiko
2021-05-20 20:14     ` Andrii Nakryiko
2021-05-20 20:44       ` Cong Wang
2021-05-21  5:12         ` Andrii Nakryiko [this message]
2021-05-21 21:49           ` Cong Wang
2021-06-03  8:10         ` Jakub Sitnicki

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=CAEf4BzYUw8bTUXEdrkRwqFg0OGsMTNe+kwxkbdqAMV9we4xifw@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=cong.wang@bytedance.com \
    --cc=daniel@iogearbox.net \
    --cc=jakub@cloudflare.com \
    --cc=jiang.wang@bytedance.com \
    --cc=john.fastabend@gmail.com \
    --cc=lmb@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.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.