Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Wed, Dec 06, 2017 at 12:01:04PM -0600, Tom Gall wrote:
> 
> 
> > On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
> >> 
> >> 
> >>> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >>> 
> >>> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
> >>>> 
> >>>> 
> >>>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >>>>> 
> >>>>> This is the start of the stable review cycle for the 4.14.4 release.
> >>>>> There are 95 patches in this series, all will be posted as a response
> >>>>> to this one.  If anyone has any issues with these being applied, please
> >>>>> let me know.
> >>>>> 
> >>>>> Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> >>>>> Anything received after that time might be too late.
> >>>>> 
> >>>>> The whole patch series can be found in one patch at:
> >>>>> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> >>>>> or in the git tree and branch at:
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> >>>>> and the diffstat can be found below.
> >>>>> 
> >>>>> thanks,
> >>>>> 
> >>>>> greg k-h
> >>>>> 
> >>>> 
> >>>> Compiled, booted and ran the following package unit tests without regressions on x86_64
> >>>> 
> >>>> boringssl : 
> >>>>  go test target:0/0/5764/5764/5764 PASS
> >>>>  ssl_test : 10 pass
> >>>>  crypto_test : 28 pass
> >>>> e2fsprogs:
> >>>>  make check : 340 pass
> >>>> sqlite
> >>>>  make test : 143914 pass
> >>>> drm
> >>>>  make check : 15 pass
> >>>>  modetest, drmdevice : pass
> >>>> alsa-lib
> >>>>  make check : 2 pass
> >>>> bluez
> >>>>  make check : 25 pass
> >>>> libusb
> >>>>  stress : 4 pass
> >>> 
> >>> How do the above tests stress the kernel?
> >> 
> >> Depends entirely on the package in question.
> >> 
> >> Sure, of completely no surprise a lot of package unit tests donât really 
> >> do much thatâs particularly interesting save to the package itself.
> > 
> > Then why run those tests?  Like sqlite, what kernel functionality does
> > that exercise that ltp does not?
> 
> Simply it beats on the system. 

There are "real" stress tests you could run if you want to do that.  But
I thought you all had a hard time keeping your boards alive, are you
sure you want to stress them?  :)

> >> There are sometimes an interesting subset that drives some amount of work in kernel. 
> >> Thatâs the useful stuff.
> > 
> > Is that true with the above list?  If so, why are those types of tests
> > not part of any kernel test suite that I have seen before?
> 
> Dunno. Canât comment on the non-action by others. What we can do is either
> harvest (by adding to say LTP) or improve in the 

I can not parse this sentence :(

> > You are testing past regressions of the userspace code, not the kernel
> > here.  Why do I care about that?  :)
> 
> Like you, I only care things that are testing the kernel. Iâm lazy.  Iâm not
> chopping out the things that go far afield, besides itâs not broken nor is it
> hurting anything.

Are you sure these are "testing" the kernel in any other way than the
existing tests you are running are?  Randomly running various userspace
programs is not really a good judge of kernel functionality coverage.

> > Don't fall down the trap of running code for the sake of running code
> > (i.e. like that web site that starts with a P) that doesn't actually
> > test anything that actually matters.
> 
> Yup entirely agree. No emerge world going on here. 8-b

'emerge world' is a wonderful test for a compiler, don't knock it, it's
found loads of bugs in the past.

But we aren't testing the compiler, we want to test the kernel, and
really, I don't think the things you ran (with maybe the exception of
the bluez test), do anything more than 'emerge world' would do :)

Why not work to incorporate one of the many tests that we already know
_do_ test different kernel functionality that you are not running before
adding random tests that no one really knows do anything at all?

thanks,

greg k-h