linux-kernel - Re: [PATCH v3] bitfield.h: add FIELD_MAX() and field

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 for Android: free password hash cracker in your pocket

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

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