cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

kselftest.rst (11334B)


      1======================
      2Linux Kernel Selftests
      3======================
      4
      5The kernel contains a set of "self tests" under the tools/testing/selftests/
      6directory. These are intended to be small tests to exercise individual code
      7paths in the kernel. Tests are intended to be run after building, installing
      8and booting a kernel.
      9
     10Kselftest from mainline can be run on older stable kernels. Running tests
     11from mainline offers the best coverage. Several test rings run mainline
     12kselftest suite on stable releases. The reason is that when a new test
     13gets added to test existing code to regression test a bug, we should be
     14able to run that test on an older kernel. Hence, it is important to keep
     15code that can still test an older kernel and make sure it skips the test
     16gracefully on newer releases.
     17
     18You can find additional information on Kselftest framework, how to
     19write new tests using the framework on Kselftest wiki:
     20
     21https://kselftest.wiki.kernel.org/
     22
     23On some systems, hot-plug tests could hang forever waiting for cpu and
     24memory to be ready to be offlined. A special hot-plug target is created
     25to run the full range of hot-plug tests. In default mode, hot-plug tests run
     26in safe mode with a limited scope. In limited mode, cpu-hotplug test is
     27run on a single cpu as opposed to all hotplug capable cpus, and memory
     28hotplug test is run on 2% of hotplug capable memory instead of 10%.
     29
     30kselftest runs as a userspace process.  Tests that can be written/run in
     31userspace may wish to use the `Test Harness`_.  Tests that need to be
     32run in kernel space may wish to use a `Test Module`_.
     33
     34Running the selftests (hotplug tests are run in limited mode)
     35=============================================================
     36
     37To build the tests::
     38
     39  $ make -C tools/testing/selftests
     40
     41To run the tests::
     42
     43  $ make -C tools/testing/selftests run_tests
     44
     45To build and run the tests with a single command, use::
     46
     47  $ make kselftest
     48
     49Note that some tests will require root privileges.
     50
     51Kselftest supports saving output files in a separate directory and then
     52running tests. To locate output files in a separate directory two syntaxes
     53are supported. In both cases the working directory must be the root of the
     54kernel src. This is applicable to "Running a subset of selftests" section
     55below.
     56
     57To build, save output files in a separate directory with O= ::
     58
     59  $ make O=/tmp/kselftest kselftest
     60
     61To build, save output files in a separate directory with KBUILD_OUTPUT ::
     62
     63  $ export KBUILD_OUTPUT=/tmp/kselftest; make kselftest
     64
     65The O= assignment takes precedence over the KBUILD_OUTPUT environment
     66variable.
     67
     68The above commands by default run the tests and print full pass/fail report.
     69Kselftest supports "summary" option to make it easier to understand the test
     70results. Please find the detailed individual test results for each test in
     71/tmp/testname file(s) when summary option is specified. This is applicable
     72to "Running a subset of selftests" section below.
     73
     74To run kselftest with summary option enabled ::
     75
     76  $ make summary=1 kselftest
     77
     78Running a subset of selftests
     79=============================
     80
     81You can use the "TARGETS" variable on the make command line to specify
     82single test to run, or a list of tests to run.
     83
     84To run only tests targeted for a single subsystem::
     85
     86  $ make -C tools/testing/selftests TARGETS=ptrace run_tests
     87
     88You can specify multiple tests to build and run::
     89
     90  $  make TARGETS="size timers" kselftest
     91
     92To build, save output files in a separate directory with O= ::
     93
     94  $ make O=/tmp/kselftest TARGETS="size timers" kselftest
     95
     96To build, save output files in a separate directory with KBUILD_OUTPUT ::
     97
     98  $ export KBUILD_OUTPUT=/tmp/kselftest; make TARGETS="size timers" kselftest
     99
    100Additionally you can use the "SKIP_TARGETS" variable on the make command
    101line to specify one or more targets to exclude from the TARGETS list.
    102
    103To run all tests but a single subsystem::
    104
    105  $ make -C tools/testing/selftests SKIP_TARGETS=ptrace run_tests
    106
    107You can specify multiple tests to skip::
    108
    109  $  make SKIP_TARGETS="size timers" kselftest
    110
    111You can also specify a restricted list of tests to run together with a
    112dedicated skiplist::
    113
    114  $  make TARGETS="bpf breakpoints size timers" SKIP_TARGETS=bpf kselftest
    115
    116See the top-level tools/testing/selftests/Makefile for the list of all
    117possible targets.
    118
    119Running the full range hotplug selftests
    120========================================
    121
    122To build the hotplug tests::
    123
    124  $ make -C tools/testing/selftests hotplug
    125
    126To run the hotplug tests::
    127
    128  $ make -C tools/testing/selftests run_hotplug
    129
    130Note that some tests will require root privileges.
    131
    132
    133Install selftests
    134=================
    135
    136You can use the "install" target of "make" (which calls the `kselftest_install.sh`
    137tool) to install selftests in the default location (`tools/testing/selftests/kselftest_install`),
    138or in a user specified location via the `INSTALL_PATH` "make" variable.
    139
    140To install selftests in default location::
    141
    142   $ make -C tools/testing/selftests install
    143
    144To install selftests in a user specified location::
    145
    146   $ make -C tools/testing/selftests install INSTALL_PATH=/some/other/path
    147
    148Running installed selftests
    149===========================
    150
    151Found in the install directory, as well as in the Kselftest tarball,
    152is a script named `run_kselftest.sh` to run the tests.
    153
    154You can simply do the following to run the installed Kselftests. Please
    155note some tests will require root privileges::
    156
    157   $ cd kselftest_install
    158   $ ./run_kselftest.sh
    159
    160To see the list of available tests, the `-l` option can be used::
    161
    162   $ ./run_kselftest.sh -l
    163
    164The `-c` option can be used to run all the tests from a test collection, or
    165the `-t` option for specific single tests. Either can be used multiple times::
    166
    167   $ ./run_kselftest.sh -c bpf -c seccomp -t timers:posix_timers -t timer:nanosleep
    168
    169For other features see the script usage output, seen with the `-h` option.
    170
    171Packaging selftests
    172===================
    173
    174In some cases packaging is desired, such as when tests need to run on a
    175different system. To package selftests, run::
    176
    177   $ make -C tools/testing/selftests gen_tar
    178
    179This generates a tarball in the `INSTALL_PATH/kselftest-packages` directory. By
    180default, `.gz` format is used. The tar compression format can be overridden by
    181specifying a `FORMAT` make variable. Any value recognized by `tar's auto-compress`_
    182option is supported, such as::
    183
    184    $ make -C tools/testing/selftests gen_tar FORMAT=.xz
    185
    186`make gen_tar` invokes `make install` so you can use it to package a subset of
    187tests by using variables specified in `Running a subset of selftests`_
    188section::
    189
    190    $ make -C tools/testing/selftests gen_tar TARGETS="bpf" FORMAT=.xz
    191
    192.. _tar's auto-compress: https://www.gnu.org/software/tar/manual/html_node/gzip.html#auto_002dcompress
    193
    194Contributing new tests
    195======================
    196
    197In general, the rules for selftests are
    198
    199 * Do as much as you can if you're not root;
    200
    201 * Don't take too long;
    202
    203 * Don't break the build on any architecture, and
    204
    205 * Don't cause the top-level "make run_tests" to fail if your feature is
    206   unconfigured.
    207
    208Contributing new tests (details)
    209================================
    210
    211 * Use TEST_GEN_XXX if such binaries or files are generated during
    212   compiling.
    213
    214   TEST_PROGS, TEST_GEN_PROGS mean it is the executable tested by
    215   default.
    216
    217   TEST_CUSTOM_PROGS should be used by tests that require custom build
    218   rules and prevent common build rule use.
    219
    220   TEST_PROGS are for test shell scripts. Please ensure shell script has
    221   its exec bit set. Otherwise, lib.mk run_tests will generate a warning.
    222
    223   TEST_CUSTOM_PROGS and TEST_PROGS will be run by common run_tests.
    224
    225   TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the
    226   executable which is not tested by default.
    227   TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
    228   test.
    229
    230 * First use the headers inside the kernel source and/or git repo, and then the
    231   system headers.  Headers for the kernel release as opposed to headers
    232   installed by the distro on the system should be the primary focus to be able
    233   to find regressions.
    234
    235 * If a test needs specific kernel config options enabled, add a config file in
    236   the test directory to enable them.
    237
    238   e.g: tools/testing/selftests/android/config
    239
    240Test Module
    241===========
    242
    243Kselftest tests the kernel from userspace.  Sometimes things need
    244testing from within the kernel, one method of doing this is to create a
    245test module.  We can tie the module into the kselftest framework by
    246using a shell script test runner.  ``kselftest/module.sh`` is designed
    247to facilitate this process.  There is also a header file provided to
    248assist writing kernel modules that are for use with kselftest:
    249
    250- ``tools/testing/selftests/kselftest_module.h``
    251- ``tools/testing/selftests/kselftest/module.sh``
    252
    253How to use
    254----------
    255
    256Here we show the typical steps to create a test module and tie it into
    257kselftest.  We use kselftests for lib/ as an example.
    258
    2591. Create the test module
    260
    2612. Create the test script that will run (load/unload) the module
    262   e.g. ``tools/testing/selftests/lib/printf.sh``
    263
    2643. Add line to config file e.g. ``tools/testing/selftests/lib/config``
    265
    2664. Add test script to makefile  e.g. ``tools/testing/selftests/lib/Makefile``
    267
    2685. Verify it works:
    269
    270.. code-block:: sh
    271
    272   # Assumes you have booted a fresh build of this kernel tree
    273   cd /path/to/linux/tree
    274   make kselftest-merge
    275   make modules
    276   sudo make modules_install
    277   make TARGETS=lib kselftest
    278
    279Example Module
    280--------------
    281
    282A bare bones test module might look like this:
    283
    284.. code-block:: c
    285
    286   // SPDX-License-Identifier: GPL-2.0+
    287
    288   #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
    289
    290   #include "../tools/testing/selftests/kselftest/module.h"
    291
    292   KSTM_MODULE_GLOBALS();
    293
    294   /*
    295    * Kernel module for testing the foobinator
    296    */
    297
    298   static int __init test_function()
    299   {
    300           ...
    301   }
    302
    303   static void __init selftest(void)
    304   {
    305           KSTM_CHECK_ZERO(do_test_case("", 0));
    306   }
    307
    308   KSTM_MODULE_LOADERS(test_foo);
    309   MODULE_AUTHOR("John Developer <jd@fooman.org>");
    310   MODULE_LICENSE("GPL");
    311
    312Example test script
    313-------------------
    314
    315.. code-block:: sh
    316
    317    #!/bin/bash
    318    # SPDX-License-Identifier: GPL-2.0+
    319    $(dirname $0)/../kselftest/module.sh "foo" test_foo
    320
    321
    322Test Harness
    323============
    324
    325The kselftest_harness.h file contains useful helpers to build tests.  The
    326test harness is for userspace testing, for kernel space testing see `Test
    327Module`_ above.
    328
    329The tests from tools/testing/selftests/seccomp/seccomp_bpf.c can be used as
    330example.
    331
    332Example
    333-------
    334
    335.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
    336    :doc: example
    337
    338
    339Helpers
    340-------
    341
    342.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
    343    :functions: TH_LOG TEST TEST_SIGNAL FIXTURE FIXTURE_DATA FIXTURE_SETUP
    344                FIXTURE_TEARDOWN TEST_F TEST_HARNESS_MAIN FIXTURE_VARIANT
    345                FIXTURE_VARIANT_ADD
    346
    347Operators
    348---------
    349
    350.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
    351    :doc: operators
    352
    353.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
    354    :functions: ASSERT_EQ ASSERT_NE ASSERT_LT ASSERT_LE ASSERT_GT ASSERT_GE
    355                ASSERT_NULL ASSERT_TRUE ASSERT_NULL ASSERT_TRUE ASSERT_FALSE
    356                ASSERT_STREQ ASSERT_STRNE EXPECT_EQ EXPECT_NE EXPECT_LT
    357                EXPECT_LE EXPECT_GT EXPECT_GE EXPECT_NULL EXPECT_TRUE
    358                EXPECT_FALSE EXPECT_STREQ EXPECT_STRNE