From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752457AbdLFSBL (ORCPT ); Wed, 6 Dec 2017 13:01:11 -0500 Received: from mail-it0-f52.google.com ([209.85.214.52]:37434 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752294AbdLFSBJ (ORCPT ); Wed, 6 Dec 2017 13:01:09 -0500 X-Google-Smtp-Source: AGs4zMbzWNF9+DsSwwzpJSRUEM0llrMamCgl1uqj/TvCSKyv2js3AF/IKuDDEJXF36Mbhfmdd6fiYA== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: [PATCH 4.14 00/95] 4.14.4-stable review From: Tom Gall In-Reply-To: <20171206064949.GA23076@kroah.com> Date: Wed, 6 Dec 2017 12:01:04 -0600 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 Message-Id: References: <20171204160046.206920966@linuxfoundation.org> <33A49DC6-C9D0-4C76-BCA4-BA1A90C42507@linaro.org> <20171205062434.GA2297@kroah.com> <20171206064949.GA23076@kroah.com> To: Greg Kroah-Hartman X-Mailer: Apple Mail (2.3445.4.7) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vB6I1G92027312 > 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 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