lkml.org 
[lkml]   [2017]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4.14 00/95] 4.14.4-stable review
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@linuxfoundation.org> 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@linuxfoundation.org> 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@linuxfoundation.org> 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

\
 
 \ /
  Last update: 2017-12-07 08:50    [W:0.074 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site