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: <CAK8P3a1NU62zf8zJAMZq5KFNuvDdrf3dUcLU4HY83Q=oDC611w@mail.gmail.com>
Date:   Thu, 2 Jan 2020 15:47:33 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Pavel Machek <pavel@....cz>
Cc:     Tony Lindgren <tony@...mide.com>, Olof Johansson <olof@...om.net>,
        kernel list <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        Sebastian Reichel <sre@...nel.org>, nekit1000@...il.com,
        Marcel Partap <mpartap@....net>, merlijn@...zup.org,
        martin_rysavy@...trum.cz
Subject: Re: Droid 4 regression in 5.5-rc1, armsoc-soc tree

On Thu, Jan 2, 2020 at 3:06 PM Pavel Machek <pavel@....cz> wrote:

> # good: [ab818f0999dc73af3f966194d087e9f6650f939f] Merge tag
> # 'omap-for-v5.5/maintainers-signed' of
> # git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
> # arm/soc
> git bisect good ab818f0999dc73af3f966194d087e9f6650f939f
> # first bad commit: [38206c24ab09b4f4c2a57de5c1af0bb2e69cf5b6] Merge tag
> # 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>
> ...and am not sure how to interpret the result, or what to do next :(.

This means that either the bisection is unreliable (it might be 100%
reproducible or you mixed up good/bad once), or that the arm-soc
branch was indeed good by itself but had a conflict with some other
change that torvalds merged earlier.

I would suggest to go back to the list I had extracted in my previous
email and revert all the commits that I identify there, on top of
linux-5.5-rc4. If some commit is not easily reverted, skip that one
at first.

Ideally this gets you a working kernel based on -rc4, and then
you can bisect that to find which revert fixed it.

        Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ