linux-kernel - Re: [PATCH 5.2 000/413] 5.2.3-stable review

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: <20190725201933.aiqh6oj7bacdwact@xps.therub.org>
Date:   Thu, 25 Jul 2019 15:19:33 -0500
From:   Dan Rue <dan.rue@...aro.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Anders Roxell <anders.roxell@...aro.org>,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        wanpengli@...cent.com,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        patches@...nelci.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        lkft-triage@...ts.linaro.org,
        linux- stable <stable@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Shuah Khan <shuah@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>, jmattson@...gle.com
Subject: Re: [PATCH 5.2 000/413] 5.2.3-stable review

On Thu, Jul 25, 2019 at 07:06:19PM +0200, Paolo Bonzini wrote:
> On 25/07/19 18:39, Dan Rue wrote:
> > To your point Paolo - reporting 'fail' because of a missing kernel
> > feature is a generic problem we see across test suites, and causes tons
> > of pain and misery for CI people. As a general rule, I'd avoid
> > submodules, and even branches that track specific kernels. Rather, and I
> > don't know if it's possible in this case, but the best way to manage it
> > from both a test author and a test runner POV is to wrap the test in
> > kernel feature checks, kernel version checks, kernel config checks, etc.
> > Report 'skip' if the environment in which the test is running isn't
> > sufficient to run the test. Then, you only have to maintain one version
> > of the test suite, users can always use the latest, and critically: all
> > failures are actual failures.
> 
> Note that kvm-unit-tests are not really testing new kernel features;
> those are covered by tools/testing/selftests/kvm.  For some of these
> kvm-unit-tests there are some CPU features that we can check from the
> virtual machine, but those are easy to handle and they produce SKIP
> results just fine.
> 
> The problematic ones are tests that cover emulation accuracy.  These are
> effectively bugfixes, so the failures you see _are_ actual failures.  At
> the same time, the bugs are usually inoffensive(*), while the fixes are
> invasive and a bad source of cause conflicts in older Linux versions.
> This combines so that backporting to stable is not feasible.

In this case, a fail result seems correct then. The thing we're doing
that we need to fix is to run against a pinned version of kvm-unit-tests
and upgrade it independently so that we can identify such failures and
mark them as known issues.

> 
> Passing the host kernel version would be really ugly because 1) the
> tests can run on other hypervisor or emulators or even bare metal, and
> of course the host kernel version has no bearing if you're using
> userspace emulation 2) there are thousands of tests that would be
> littered with kernel version checks of little significance.
> 
> So this is why I suggested a submodule: using a submodule effectively
> ignores all tests that were added after a given Linus release, and thus
> all the failures for which backports are just not going to happen.
> However, if Sean's idea of creating a linux-M.N branch in
> kvm-unit-tests.git works for you, we can also do that as a stopgap
> measure to ease your testing.

I would still prefer to run the latest tests against all kernel versions
(but better control when we upgrade it). Like I said, we can handle
expected failures, and it would even help to validate backports for
fixes that do get backported. I'm afraid on your behalf that snapping
(and maintaining) branches per kernel branch is going to be a lot to
manage.

In any case, _thank you so much_ for jumping on this and helping us run
these tests. Is there anything else we can do to make this better for
you?

Dan

> 
> Thanks,
> 
> Paolo
> 
> (*) if they aren't, we *do* mark them for backport!

-- 
Linaro - Kernel Validation