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: <CAKwvOdnO2=yjEerw50b_C2vrgdCh2es6ZRfQpBRVR9RCrvwi6Q@mail.gmail.com>
Date:   Wed, 1 Apr 2020 17:26:29 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Alex Elder <elder@...aro.org>,
        Maxim Kuvyrkov <maxim.kuvyrkov@...aro.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        "David S. Miller" <davem@...emloft.net>,
        Johannes Berg <johannes@...solutions.net>,
        Jakub Kicinski <kuba@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan Chancellor <natechancellor@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v3] bitfield.h: add FIELD_MAX() and field_max()

On Wed, Apr 1, 2020 at 4:18 PM Alex Elder <elder@...aro.org> wrote:
>
> On 4/1/20 5:26 PM, Nick Desaulniers wrote:
> >
> > mainline is hosed for aarch64 due to some dtc failures.  I'm not sure
> > how TCWG's CI chooses the bisection starting point, but if mainline
> > was broken, and it jumped back say 300 commits, then the automated
> > bisection may have converged on your first patch, but not the second.
>
> This is similar to the situation I discussed with Maxim this
> morning.  A different failure (yes, DTC related) led to an
> automated bisect process, which landed on my commit. And my
> commit unfortunately has the the known issue that was later
> corrected.
>
> Maxim said this was what started the automated bisect:
> ===
> +# 00:01:41 make[2]: *** [arch/arm64/boot/dts/ti/k3-am654-base-board.dtb] Error 2
> +# 00:01:41 make[2]: *** [arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb] Error 2
> +# 00:01:41 make[1]: *** [arch/arm64/boot/dts/ti] Error 2
> +# 00:01:41 make: *** [dtbs] Error 2

DTC thread:
https://lore.kernel.org/linux-arm-kernel/20200401223500.224253-1-ndesaulniers@google.com/

Maxim, can you describe how the last known good sha is chosen?  If you
persist anything between builds, like ccache dir, maybe you could
propagate a sha of the last successful build, updating it if no
regression occurred?  Then that can always be a precise last known
good sha.  Though I don't know if the merge commits complicate this.
-- 
Thanks,
~Nick Desaulniers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ