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