linux-kernel - Re: [PATCH 4.9 000/104] 4.9.54-stable review

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:   Tue, 10 Oct 2017 11:39:09 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Tom Gall <tom.gall@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
        Shuah Khan <shuahkh@....samsung.com>, patches@...nelci.org,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        linux- stable <stable@...r.kernel.org>
Subject: Re: [PATCH 4.9 000/104] 4.9.54-stable review

On Tue, Oct 10, 2017 at 05:33:04PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Oct 10, 2017 at 10:23:43AM -0500, Tom Gall wrote:
> > On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> > > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
> > >> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
> > >> <gregkh@...uxfoundation.org> wrote:
> > >> >> kernel: 4.9.54-rc1
> > >> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > >> >> git branch: linux-4.9.y
> > >> >> git commit: 1852eae92c460813692808234da35d142a405ab7
> > >> >> git describe: v4.9.53
> > >> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
> > >>
> > >> >>
> > >> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
> > >> >
> > >> > How did your arm64 test build?  There was a build regression in the -rc1
> > >> > release, are you sure you actually ran the correct image?
> > >>
> > >> So the header in that report was wrong. That's a c/n/p error on my
> > >> part. I was in a rush to get you data before I was going to be gone
> > >> for the day on Sat and wanting to get what we had into your hands
> > >> before the Sunday deadline.
> > >>
> > >> The test results was for the RC as of commit
> > >> 0e59436504287cddb9663857ae69c100b55f5e85
> > >>
> > >> If you want to see the 'ugly' raw data it's all here :
> > >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
> > >
> > > I still don't understand.  That _build_ should have failed, how did it
> > > succeed enough to actually run the tests at all?
> > 
> > Looks like it's because we don't build with CONFIG_KASAN.
> 
> Ick, not good, why not?  Surely you enable all of the options you can
> for your hardware, right?  And enabling stuff like this is good no
> matter what...
> 
FWIW, I don't enable CONFIG_KASAN or my qemu test runs either, simply because
enabling it makes images all but impossible to run in qemu. Whatever KASAN
does, it seems to completely defeat qemu.

> > In the case where the build fails, the system won't run tests since there's no
> > image to run. Likewise if we have a situation where the build fails
> > for some arches
> > but not all we'll only get partial test results for the builds that
> > succeeded and
> > likewise nothing for what failed.
> 
> Ok, good (odd line-wrapping, did I give you too many '\n'?)
> 
> > The results reported were based on commit id
> > 0e59436504287cddb9663857ae69c100b55f5e85
> > 
> > Unfortunately that commit id doesn't exist anymore since it was
> > replaced by the 4.9.54 release which was commit ID
> > f37eb7b586f1dd24a86c50278c65322fc6787722
> > 
> > (and yes the release test results == rc test results that were reported)
> > 
> > Things get a little confusing when one can't go back and compare
> > commit ids. Losing history kinda sucks.
> > 
> > I've thought about some other way to uniquely tie results to an rc
> > patch maybe working
> > off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/
> > 
> > But like in this instance if there isn't both the rc1 and rc2 for
> > posterity it wouldn't help.
> > Least for now we have commit ids, git describe and kernel version from
> > the Makefile.
> > 
> > Why wasn't there an rc2 patch file?
> 
> There was, I announced it.  But oh, look, I never pushed it out to
> kernel.org, my fault.  I guess no one actually tested it except me :)
> 
Hmm, I am pretty sure that my builders picked it up from the git repo
since the previously failing builds started to pass.

Guenter