linux-kernel - Re: [PATCH] selftests/vm: enable running select groups of tests

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:   Wed, 6 Jul 2022 14:38:03 -0400
From:   Nico Pache <npache@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Joel Savitz <jsavitz@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Shuah Khan <shuah@...nel.org>, Linux MM <linux-mm@...ck.org>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] selftests/vm: enable running select groups of tests

On Tue, Jul 5, 2022 at 4:35 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Tue,  5 Jul 2022 14:56:05 -0400 Joel Savitz <jsavitz@...hat.com> wrote:
>
> > Add the ability to run one or more groups of vm tests (specified
> > by the environment variable TEST_ITEMS). Preserve existing default
> > behavior of running all tests when TEST_ITEMS is empty or "default".
>
Hi Andrew,

> What is the reason for this?  What's the use case?

The current design of vm selftests is all-or-none. We'd like to be
able to selectively run these tests (We settled for selective groups
of tests rather than individual tests).

The main reason for doing this is our efforts to expand RedHats MM CI
testing. There are two use cases for these changes that relate to our
reasoning:
1) Our current CI has overlapping tests between LTP and vm selftests,
so we'd like a way to prevent running the same test in two places.
2) We'd like the ability to skip a test if it is determined to be
unstable or requires certain hardware requirements.

By adding this functionality we are really expanding what we are able
to do with the stock vm-selftests.

> And why via the environment rather than via commandline args?
Just a design choice I suppose. I'm sure Joel would be willing to
implement it as a cmdline arg if you'd prefer that approach.

Cheers,
-- Nico