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