1. 19 Oct, 2021 6 commits
    • Daniel Latypov's avatar
      kunit: add 'kunit.action' param to allow listing out tests · 9c6b0e1d
      Daniel Latypov authored
      Context:
      It's difficult to map a given .kunitconfig => set of enabled tests.
      Letting kunit.py figure that out would be useful.
      
      This patch:
      * is intended to be an implementation detail used only by kunit.py
      * adds a kunit.action module param with one valid non-null value, "list"
      * for the "list" action, it simply prints out "<suite>.<test>"
      * leaves the kunit.py changes to make use of this for another patch.
      
      Note: kunit.filter_glob is respected for this and all future actions.
      
      Hack: we print a TAP header (but no test plan) to allow kunit.py to
      use the same code to pick up KUnit output that it does for normal tests.
      Since this is intended to be an implementation detail, it seems fine for
      now. Maybe in the future we output each test as SKIPPED or the like.
      
      Go with a more generic "action" param, since it seems like we might
      eventually have more modes besides just running or listing tests, e.g.
      * perhaps a benchmark mode that reruns test cases and reports timing
      * perhaps a deflake mode that reruns test cases that failed
      * perhaps a mode where we randomize test order to try and catch
        hermeticity bugs like "test a only passes if run after test b"
      
      Tested:
      $ ./tools/testing/kunit/kunit.py run --kernel_arg=kunit.action=list --raw_output=kunit
      ...
      TAP version 14
      1..1
      example.example_simple_test
      example.example_skip_test
      example.example_mark_skipped_test
      reboot: System halted
      Signed-off-by: default avatarDaniel Latypov <dlatypov@google.com>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Reviewed-by: default avatarBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      9c6b0e1d
    • Daniel Latypov's avatar
      kunit: tool: show list of valid --arch options when invalid · fe678fed
      Daniel Latypov authored
      Consider this attempt to run KUnit in QEMU:
      $ ./tools/testing/kunit/kunit.py run --arch=x86
      
      Before you'd get this error message:
      kunit_kernel.ConfigError: x86 is not a valid arch
      
      After:
      kunit_kernel.ConfigError: x86 is not a valid arch, options are ['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc', 'x86_64']
      
      This should make it a bit easier for people to notice when they make
      typos, etc. Currently, one would have to dive into the python code to
      figure out what the valid set is.
      Signed-off-by: default avatarDaniel Latypov <dlatypov@google.com>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Reviewed-by: default avatarBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      fe678fed
    • Daniel Latypov's avatar
      kunit: tool: misc fixes (unused vars, imports, leaked files) · a54ea2e0
      Daniel Latypov authored
      Drop some variables in unit tests that were unused and/or add assertions
      based on them.
      
      For ExitStack, it was imported, but the `es` variable wasn't used so it
      didn't do anything, and we were leaking the file objects.
      Refactor it to just use nested `with` statements to properly close them.
      
      And drop the direct use of .close() on file objects in the kunit tool
      unit test, as these can be leaked if test assertions fail.
      Signed-off-by: default avatarDaniel Latypov <dlatypov@google.com>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Reviewed-by: default avatarBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      a54ea2e0
    • Daniel Latypov's avatar
      kunit: fix too small allocation when using suite-only kunit.filter_glob · cd94fbc2
      Daniel Latypov authored
      When a user filters by a suite and not a test, e.g.
      $ ./tools/testing/kunit/kunit.py run 'suite_name'
      
      it hits this code
        const int len = strlen(filter_glob);
        ...
        parsed->suite_glob = kmalloc(len, GFP_KERNEL);
      which fails to allocate space for the terminating NULL.
      
      Somehow, it seems like we can't easily reproduce this under UML, so the
      existing `parse_filter_test()` didn't catch this.
      
      Fix this by allocating `len + 1` and switch to kzalloc() just to be a
      bit more defensive. We're only going to run this code once per kernel
      boot, and it should never be very long.
      
      Also update the unit tests to be a bit more cautious.
      This bug showed up as a NULL pointer dereference here:
      >  KUNIT_EXPECT_STREQ(test, (const char *)filtered.start[0][0]->name, "suite0");
      `filtered.start[0][0]` was NULL, and `name` is at offset 0 in the struct,
      so `...->name` was also NULL.
      
      Fixes: 3b29021ddd10 ("kunit: tool: allow filtering test cases via glob")
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Signed-off-by: default avatarDaniel Latypov <dlatypov@google.com>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Acked-by: default avatarBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      cd94fbc2
    • Daniel Latypov's avatar
      kunit: tool: allow filtering test cases via glob · a127b154
      Daniel Latypov authored
      Commit 1d71307a ("kunit: add unit test for filtering suites by
      names") introduced the ability to filter which suites we run via glob.
      
      This change extends it so we can also filter individual test cases
      inside of suites as well.
      
      This is quite useful when, e.g.
      * trying to run just the tests cases you've just added or are working on
      * trying to debug issues with test hermeticity
      
      Examples:
      $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit '*exec*.parse*'
      ...
      ============================================================
      ======== [PASSED] kunit_executor_test ========
      [PASSED] parse_filter_test
      ============================================================
      Testing complete. 1 tests run. 0 failed. 0 crashed.
      
      $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit '*.no_matching_tests'
      ...
      [ERROR] no tests run!
      Signed-off-by: default avatarDaniel Latypov <dlatypov@google.com>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Reviewed-by: default avatarBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      a127b154
    • Daniel Latypov's avatar
      kunit: drop assumption in kunit-log-test about current suite · b7cbaef3
      Daniel Latypov authored
      This test assumes that the declared kunit_suite object is the exact one
      which is being executed, which KUnit will not guarantee [1].
      
      Specifically, `suite->log` is not initialized until a suite object is
      executed. So if KUnit makes a copy of the suite and runs that instead,
      this test dereferences an invalid pointer and (hopefully) segfaults.
      
      N.B. since we no longer assume this, we can no longer verify that
      `suite->log` is *not* allocated during normal execution.
      
      An alternative to this patch that would allow us to test that would
      require exposing an API for the current test to get its current suite.
      Exposing that for one internal kunit test seems like overkill, and
      grants users more footguns (e.g. reusing a test case in multiple suites
      and changing behavior based on the suite name, dynamically modifying the
      setup/cleanup funcs, storing/reading stuff out of the suite->log, etc.).
      
      [1] In a subsequent patch, KUnit will allow running subsets of test
      cases within a suite by making a copy of the suite w/ the filtered test
      list. But there are other reasons KUnit might execute a copy, e.g. if it
      ever wants to support parallel execution of different suites, recovering
      from errors and restarting suites
      Signed-off-by: default avatarDaniel Latypov <dlatypov@google.com>
      Reviewed-by: default avatarBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      b7cbaef3
  2. 18 Oct, 2021 17 commits
  3. 17 Oct, 2021 3 commits
  4. 16 Oct, 2021 14 commits