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]

Date:   Mon, 19 Jun 2017 19:32:38 +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 Mon, Jun 19, 2017 at 10:55:01PM +0800, Greg Kroah-Hartman wrote:
> On Mon, Jun 19, 2017 at 04:48:05PM +0200, Luis R. Rodriguez wrote:
> > On Sat, Jun 17, 2017 at 06:16:35AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 16, 2017 at 09:47:21PM +0200, Luis R. Rodriguez wrote:
> > > > 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.
> > > 
> > > I don't understand, what do you mean by "pick these test driver
> > > enhancements"?  What kind of "knobs" are there in tests?  Shouldn't the
> > > tests "just work" with no kind of special configuration of the tests be
> > > needed?  No user is going to know to enable something special.
> > 
> > Test driver knobs, so for instance the async and custom patches referenced
> > enable the shell script to use the async api and the custom API.
> 
> Ah, testing kernel code, that makes more sense.  I don't really know, if
> the apis are present in the older kernel trees, I don't have a problem
> having them be backported to stable kernel releases, as this isn't code
> that people are actually running on a "normal" system.

Wonderful, will peg test-driver changes as stable then when this fits. I really
do think this will make test coverage better.

  Luis