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]
Date:   Thu, 24 Sep 2020 08:43:25 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        John Fastabend <john.fastabend@...il.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Eelco Chaudron <echaudro@...hat.com>,
        KP Singh <kpsingh@...omium.org>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v8 04/11] bpf: move prog->aux->linked_prog and
 trampoline into bpf_link on attach

On Thu, Sep 24, 2020 at 7:34 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> ...which I just put down to random breakage, turned off the umh and
> continued on my way (ignoring the failed test). Until you wrote this I
> did not suspect this would be something I needed to pay attention to.
> Now that you did mention it, I'll obviously go investigate some more, my
> point is just that in this instance it's not accurate to assume I just
> didn't run the tests... :)

Ignoring failures is the same as not running them.
I expect all developers to confirm that they see "0 FAILED" before
sending any patches.

>
> > I think I will just start marking patches as changes-requested when I see that
> > they break tests without replying and without reviewing.
> > Please respect reviewer's time.
>
> That is completely fine if the tests are working in the first place. And
> even when they're not (like in this case), pointing it out is fine, and
> I'll obviously go investigate. But please at least reply to the email,
> not all of us watch patchwork regularly.

Please see Documentation/bpf/bpf_devel_QA.rst.
patchwork status is the way we communicate the intent.
If the patch is not in the queue it won't be acted upon.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ