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? > 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? > 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? :) 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. thanks, greg k-h