linux-kernel - Re: LTS testing with latest kselftests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170616194721.GE21846@wotan.suse.de>
Date:   Fri, 16 Jun 2017 21:47:21 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Brian Norris <computersforpeace@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Fengguang Wu <fengguang.wu@...el.com>, shuah@...nel.org,
        LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
        linux-kselftest@...r.kernel.org, yi1.li@...ux.intel.com,
        takahiro.akashi@...aro.org, Martin Fuzzey <mfuzzey@...keon.com>,
        Alan Cox <alan@...ux.intel.com>
Subject: Re: LTS testing with latest kselftests - some failures

On Fri, Jun 16, 2017 at 09:29:52PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 16, 2017 at 06:46:51PM +0200, Luis R. Rodriguez wrote:
> > Kees, please review 47e0bbb7fa98 below.
> > Brian, please review be4a1326d12c below.
> > 
> > On Thu, Jun 15, 2017 at 11:26:53PM +0530, Sumit Semwal wrote:
> > > Hello Greg, Shuah,
> > > 
> > > While testing 4.4.y and 4.9.y LTS kernels with latest kselftest,
> > 
> > To be clear it seems like you are taking the latest upstream ksefltest and run
> > it against older stable kernels. Furthermore you seem to only run the shell
> > script tests but are using older kselftests drivers? Is this all correct?
> > Otherwise it is unclear how you are running into the issues below.
> > 
> > Does 0-day so the same? I thought 0-day takes just the kselftest from each tree
> > submitted. That *seemed* to me like the way it was designed. Shuah ?
> > 
> > What's the name of *this* testing effort BTW? Is this part of the overall
> > kselftest ? Or is this something Linaro does for LTS kernels ? If there
> > is a name to your effort can you document it here so that others are aware:
> 
> It's a "test LTS kernels to make sure Greg didn't break anything" type
> of testing effort that Linaro is helping out with.

OK so its "standard" :)

> This could also be called, "it's about time someone did this..." :)

Good to know!

> > > we found a couple more test failures due to test-kernel mismatch:
> > > 
> > > 1. firmware tests: - linux 4.5 [1] and 4.10 [2] added a few updates to
> > > tests, and related updates to lib/test_firmware.c to improve the
> > > tests. Stable-4.4 misses these patches to lib/test_firmware.c. Stable
> > > 4.9 misses the second update.
> > 
> > <-- snip, skipped 2. and 3. -->
> > 
> > > For all the 3 listed above, we will try and update the tests to gracefully exit.
> > 
> > Hmm, this actually raises a good kselftest question:
> > 
> > I *though* kselftests were running tests on par with the kernels, so we would
> > *not* take latest upstream kselftests to test against older kernels. Is this
> > incorrect?
> 
> That is incorrect.  Your test should always degrade gracefully if the
> feature is not present in the kernel under test.

OK perfect, now I know to look for knobs in the shell tests to ensure this
doesn't happen again.

Some of the knobs however are for extending tests for
existing APIs in older kernels, the async and custom fallback one are an
example.  There are a series of test cases later added which could help
test LTS kernels. Would Linaro pick these test driver enhancements to help
increase coverage of tests? Or is it not worth it? If its worth it then
what I was curious was how to help make this easier for this process to
bloom.

> If the test is for a
> bug that was fixed, then that fix should also go to a stable kernel
> release.

Indeed, that was perfectly clear.

  Luis