Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751043AbdLGHtc (ORCPT ); Thu, 7 Dec 2017 02:49:32 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:33500 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750744AbdLGHta (ORCPT ); Thu, 7 Dec 2017 02:49:30 -0500 Date: Thu, 7 Dec 2017 08:49:37 +0100 From: Greg Kroah-Hartman To: Tom Gall Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, Guenter Roeck , shuahkh@osg.samsung.com, patches@kernelci.org, ben.hutchings@codethink.co.uk, lkft-triage@lists.linaro.org, linux- stable Subject: Re: [PATCH 4.14 00/95] 4.14.4-stable review Message-ID: <20171207074937.GB5623@kroah.com> References: <20171204160046.206920966@linuxfoundation.org> <33A49DC6-C9D0-4C76-BCA4-BA1A90C42507@linaro.org> <20171205062434.GA2297@kroah.com> <20171206064949.GA23076@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4161 Lines: 112 On Wed, Dec 06, 2017 at 12:01:04PM -0600, Tom Gall wrote: > > > > On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman 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 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 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