linux-kernel - Re: [PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ

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: <alpine.LRH.2.21.2006021743430.17227@localhost>
Date:   Tue, 2 Jun 2020 17:53:27 +0100 (BST)
From:   Alan Maguire <alan.maguire@...cle.com>
To:     David Gow <davidgow@...gle.com>
cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        alan.maguire@...cle.com, Jonathan Corbet <corbet@....net>,
        linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation: kunit: Add some troubleshooting tips to
 the FAQ

On Mon, 1 Jun 2020, David Gow wrote:

> Add an FAQ entry to the KUnit documentation with some tips for
> troubleshooting KUnit and kunit_tool.
> 
> These suggestions largely came from an email thread:
> https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b947ff@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03
> 
> Signed-off-by: David Gow <davidgow@...gle.com>
> ---
>  Documentation/dev-tools/kunit/faq.rst | 32 +++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst
> index ea55b2467653..40109d425988 100644
> --- a/Documentation/dev-tools/kunit/faq.rst
> +++ b/Documentation/dev-tools/kunit/faq.rst
> @@ -61,3 +61,35 @@ test, or an end-to-end test.
>    kernel by installing a production configuration of the kernel on production
>    hardware with a production userspace and then trying to exercise some behavior
>    that depends on interactions between the hardware, the kernel, and userspace.
> +
> +KUnit isn't working, what should I do?
> +======================================
> +
> +Unfortunately, there are a number of things which can break, but here are some
> +things to try.
> +
> +1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output``
> +   parameter. This might show details or error messages hidden by the kunit_tool
> +   parser.
> +2. Instead of running ``kunit.py run``, try running ``kunit.py config``,
> +   ``kunit.py build``, and ``kunit.py exec`` independently. This can help track
> +   down where an issue is occurring. (If you think the parser is at fault, you
> +   can run it manually against stdin or a file with ``kunit.py parse``.)
> +3. Running the UML kernel directly can often reveal issues or error messages
> +   kunit_tool ignores. This should be as simple as running ``./vmlinux`` after
> +   building the UML kernel (e.g., by using ``kunit.py build``). Note that UML
> +   has some unusual requirements (such as the host having a tmpfs filesystem
> +   mounted), and has had issues in the past when built statically and the host
> +   has KASLR enabled. (On older host kernels, you may need to run ``setarch
> +   `uname -m` -R ./vmlinux`` to disable KASLR.)
> +4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test
> +   (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config
> +   around, so you can see what config was used after running ``kunit.py run``.
> +   It also preserves any config changes you might make, so you can
> +   enable/disable things with ``make ARCH=um menuconfig`` or similar, and then
> +   re-run kunit_tool.
> +5. Finally, running ``make ARCH=um defconfig`` before running ``kunit.py run``
> +   may help clean up any residual config items which could be causing problems.
> +

Looks great! Could we add something like:

6. Try running kunit standalone (without UML).  KUnit and associated 
tests can be built into a standard kernel or built as a module; doing
so allows us to verify test behaviour independent of UML so can be
useful to do if running under UML is failing.  When tests are built-in
they will execute on boot, and modules will automatically execute
associated tests when loaded.  Test results can be collected from
/sys/kernel/debug/kunit/<test-suite>/results. For more details see
"KUnit on non-UML architectures" in :doc:`usage`. 

Reviewed-by: Alan Maguire <alan.maguire@...cle.com>