> On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman <gre...@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 >>> <gre...@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 >>>>> <gre...@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 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 > >> Take bluez, and it’s use of CONFIG_CRYPTO_USER_API. > > Nice, does that cover things that is not in LTP? Should those tests be > added to LTP? > >>> Aren't they just >>> verifications that the source code in the package is correct? >> >> So if there’s some useful subset, that’s what I’m looking for. >> >>> I guess it proves something, but have you ever seen the above regress in >>> _any_ kernel release? >> >> Past regressions make for a good test. > > 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. > 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 > thanks, > > greg k-h
