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

[Greg Kroah-Hartman]

On Tue, Oct 10, 2017 at 11:39:09AM -0700, Guenter Roeck wrote:
> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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.

Yes, the git trees pushed out properly, but the -rc2 patch has to get
sent up manually with a different script.

It's all patched together here to barely work...

thanks,

greg k-h