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

[Greg Kroah-Hartman]

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...

> 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 :)

Going off of the quilt tree might be good, that's what others do today
(hint...)

thanks,

greg k-h