- Linux-kselftest-mirror - lists.linaro.org

[PATCH] Documentation: Kunit: Update architecture.rst for minor fixes

by Sadiya Kazi

Updated the architecture.rst page with the following changes: -Add missing article _the_ across the document. -Reword content across for style and standard. -Upate all occurrences of Command Line to Command-line across the document. -Correct grammatical issues, for example - added _it_wherever missing. -Update all occurrences of _via_ to either use _through_ or _using_. -Update the text preceding the external links and pushed the full link to a new line for better readability. -Reword content under the config command to make it more clear and concise. Signed-off-by: Sadiya Kazi <sadiyakazi(a)google.com> --- .../dev-tools/kunit/architecture.rst | 86 ++++++++++--------- 1 file changed, 45 insertions(+), 41 deletions(-) diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst index 8efe792bdcb9..1736c37c33f2 100644 --- a/Documentation/dev-tools/kunit/architecture.rst +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -4,16 +4,17 @@ KUnit Architecture ================== -The KUnit architecture can be divided into two parts: +The KUnit architecture is divided into two parts: - `In-Kernel Testing Framework`_ -- `kunit_tool (Command Line Test Harness)`_ +- `kunit_tool (Command-line Test Harness)`_ In-Kernel Testing Framework =========================== The kernel testing library supports KUnit tests written in C using -KUnit. KUnit tests are kernel code. KUnit does several things: +KUnit. KUnit tests are written in the kernel code. KUnit performs the following +tasks: - Organizes tests - Reports test results @@ -22,8 +23,8 @@ KUnit. KUnit tests are kernel code. KUnit does several things: Test Cases ---------- -The fundamental unit in KUnit is the test case. The KUnit test cases are -grouped into KUnit suites. A KUnit test case is a function with type +The test case is the fundamental unit in KUnit. KUnit test cases are organised +into suites. A KUnit test case is a function with type signature ``void (*)(struct kunit *test)``. These test case functions are wrapped in a struct called struct kunit_case. @@ -31,8 +32,8 @@ struct kunit_case. .. note: ``generate_params`` is optional for non-parameterized tests. -Each KUnit test case gets a ``struct kunit`` context -object passed to it that tracks a running test. The KUnit assertion +Each KUnit test case receives a ``struct kunit`` context object that tracks a +running test. The KUnit assertion macros and other KUnit utilities use the ``struct kunit`` context object. As an exception, there are two fields: @@ -77,11 +78,12 @@ Executor The KUnit executor can list and run built-in KUnit tests on boot. The Test suites are stored in a linker section -called ``.kunit_test_suites``. For code, see: +called ``.kunit_test_suites``. For code, see the following link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc…. + The linker section consists of an array of pointers to ``struct kunit_suite``, and is populated by the ``kunit_test_suites()`` -macro. To run all tests compiled into the kernel, the KUnit executor +macro. To run all the compiled tests into the kernel, the KUnit executor iterates over the linker section array. .. kernel-figure:: kunit_suitememorydiagram.svg @@ -90,8 +92,8 @@ iterates over the linker section array. KUnit Suite Memory Diagram On the kernel boot, the KUnit executor uses the start and end addresses -of this section to iterate over and run all tests. For code, see: -https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/executor.c +of this section to iterate over and run all tests. For code, see the following link: +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/executor.c. When built as a module, the ``kunit_test_suites()`` macro defines a ``module_init()`` function, which runs all the tests in the compilation @@ -99,46 +101,48 @@ unit instead of utilizing the executor. In KUnit tests, some error classes do not affect other tests or parts of the kernel, each KUnit case executes in a separate thread -context. For code, see: +context. For code, see the following link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib… Assertion Macros ---------------- -KUnit tests verify state using expectations/assertions. +KUnit tests verify the state using expectations/assertions. All expectations/assertions are formatted as: ``KUNIT_{EXPECT|ASSERT}_<op>[_MSG](kunit, property[, message])`` - ``{EXPECT|ASSERT}`` determines whether the check is an assertion or an expectation. - - For an expectation, if the check fails, marks the test as failed + - For an expectation, if the check fails, it marks the test as failed and logs the failure. - An assertion, on failure, causes the test case to terminate immediately. - - Assertions call function: + - Assertion calls the function: ``void __noreturn kunit_abort(struct kunit *)``. - - ``kunit_abort`` calls function: + - ``kunit_abort`` calls the function: ``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``. - - ``kunit_try_catch_throw`` calls function: + - ``kunit_try_catch_throw`` calls the function: ``void kthread_complete_and_exit(struct completion *, long) __noreturn;`` and terminates the special thread context. - ``<op>`` denotes a check with options: ``TRUE`` (supplied property - has the boolean value “true”), ``EQ`` (two supplied properties are + has the boolean value "true"), ``EQ`` (two supplied properties are equal), ``NOT_ERR_OR_NULL`` (supplied pointer is not null and does not - contain an “err” value). + contain an "err" value). - ``[_MSG]`` prints a custom message on failure. Test Result Reporting --------------------- -KUnit prints test results in KTAP format. KTAP is based on TAP14, see: +KUnit prints the test results in KTAP format. +KTAP is based on TAP14, see: https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-…. + KTAP (yet to be standardized format) works with KUnit and Kselftest. The KUnit executor prints KTAP results to dmesg, and debugfs (if configured). @@ -151,32 +155,32 @@ parameters. The test is invoked multiple times, once for each parameter value and the parameter is stored in the ``param_value`` field. The test case includes a KUNIT_CASE_PARAM() macro that accepts a generator function. -The generator function is passed the previous parameter and returns the next -parameter. It also provides a macro to generate common-case generators based on -arrays. +The previous parameter is passed to the generator function, which returns +the next parameter. It also includes a macro for generating array-based +common-case generators. -kunit_tool (Command Line Test Harness) +kunit_tool (Command-line Test Harness) ====================================== -kunit_tool is a Python script ``(tools/testing/kunit/kunit.py)`` -that can be used to configure, build, exec, parse and run (runs other -commands in order) test results. You can either run KUnit tests using -kunit_tool or can include KUnit in kernel and parse manually. +``kunit_tool`` is a Python script, found in ``tools/testing/kunit/kunit.py``. It +is used to configure, build, execute, parse, and run (other commands in order) +test results. You have two options for running KUnit tests: either include KUnit +in the kernel and parse manually, or use the ``kunit_tool``. - ``configure`` command generates the kernel ``.config`` from a ``.kunitconfig`` file (and any architecture-specific options). - For some architectures, additional config options are specified in the - ``qemu_config`` Python script - (For example: ``tools/testing/kunit/qemu_configs/powerpc.py``). + The Python script available in ``qemu_configs`` folder + (for example, ``tools/testing/kunit/qemu configs/powerpc.py``) contains + additional configuration options for specific architectures. It parses both the existing ``.config`` and the ``.kunitconfig`` files - and ensures that ``.config`` is a superset of ``.kunitconfig``. - If this is not the case, it will combine the two and run - ``make olddefconfig`` to regenerate the ``.config`` file. It then - verifies that ``.config`` is now a superset. This checks if all - Kconfig dependencies are correctly specified in ``.kunitconfig``. - ``kunit_config.py`` includes the parsing Kconfigs code. The code which - runs ``make olddefconfig`` is a part of ``kunit_kernel.py``. You can - invoke this command via: ``./tools/testing/kunit/kunit.py config`` and + to ensure that ``.config`` is a superset of ``.kunitconfig``. + If not, it will combine the two and execute ``make olddefconfig`` to regenerate + the ``.config`` file. It then checks to see if ``.config`` has become a superset. + This verifies that all the Kconfig dependencies are correctly specified in the file + ``.kunitconfig``. The + ``kunit_config.py`` script contains the code for parsing Kconfigs. The code which + runs ``make olddefconfig`` is part of the ``kunit_kernel.py`` script. You can + invoke this command through: ``./tools/testing/kunit/kunit.py config`` and generate a ``.config`` file. - ``build`` runs ``make`` on the kernel tree with required options (depends on the architecture and some options, for example: build_dir) @@ -184,8 +188,8 @@ kunit_tool or can include KUnit in kernel and parse manually. To build a KUnit kernel from the current ``.config``, you can use the ``build`` argument: ``./tools/testing/kunit/kunit.py build``. - ``exec`` command executes kernel results either directly (using - User-mode Linux configuration), or via an emulator such - as QEMU. It reads results from the log via standard + User-mode Linux configuration), or through an emulator such + as QEMU. It reads results from the log using standard output (stdout), and passes them to ``parse`` to be parsed. If you already have built a kernel with built-in KUnit tests, you can run the kernel and display the test results with the ``exec`` -- 2.38.0.rc1.362.ged0d419d3c-goog

3 years, 1 month

3
2
0 0

[PATCH -next] selftests/memory-hotplug: Remove the redundant warning information

by Zhao Gongyi

Remove the redundant warning information of online_all_offline_memory() since there is a warning in online_memory_expect_success(). Signed-off-by: Zhao Gongyi <zhaogongyi(a)huawei.com> --- tools/testing/selftests/memory-hotplug/mem-on-off-test.sh | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh index 74ee5067a8ce..611be86eaf3d 100755 --- a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh +++ b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh @@ -138,7 +138,6 @@ online_all_offline_memory() { for memory in `hotpluggable_offline_memory`; do if ! online_memory_expect_success $memory; then - echo "$FUNCNAME $memory: unexpected fail" >&2 retval=1 fi done -- 2.17.1

3 years, 1 month

2
1
0 0

[PATCH bpf v3 0/6] Fix bugs found by ASAN when running selftests

by Xu Kuohai

v3: - Fix error failure of case test_xdp_adjust_tail_grow exposed by this series v2: https://lore.kernel.org/bpf/20221010070454.577433-1-xukuohai@huaweicloud.com - Rebase and fix conflict v1: https://lore.kernel.org/bpf/20221009131830.395569-1-xukuohai@huaweicloud.com Xu Kuohai (6): libbpf: Fix use-after-free in btf_dump_name_dups libbpf: Fix memory leak in parse_usdt_arg() selftests/bpf: Fix memory leak caused by not destroying skeleton selftest/bpf: Fix memory leak in kprobe_multi_test selftests/bpf: Fix error failure of case test_xdp_adjust_tail_grow selftest/bpf: Fix error usage of ASSERT_OK in xdp_adjust_tail.c tools/lib/bpf/btf_dump.c | 47 +++++++++++---- tools/lib/bpf/usdt.c | 59 +++++++++++-------- .../bpf/prog_tests/kprobe_multi_test.c | 17 +++--- .../selftests/bpf/prog_tests/map_kptr.c | 3 +- .../selftests/bpf/prog_tests/tracing_struct.c | 3 +- .../bpf/prog_tests/xdp_adjust_tail.c | 7 ++- 6 files changed, 86 insertions(+), 50 deletions(-) -- 2.30.2

3 years, 1 month

2
14
0 0

Re: [PATCH -next v5 2/4] selftests/memory-hotplug: Restore memory before exit

by zhaogongyi

Hi Shuah, David, I am sorry for my slow response, I have submit a new patch to fix it. Please see: https://patchwork.kernel.org/project/linux-kselftest/patch/20221011013926.2… Thanks, Gongyi > > On 10/10/22 00:54, David Hildenbrand wrote: > > On 08.10.22 03:40, zhaogongyi wrote: > > >> > >> Yes, online_memory_expect_success() already prints a warning, > remove > >> the warning in online_all_offline_memory() seems ok, > >> > >> My previous consideration was that one more log information would > make it easier to locate the wrong location. > > > > Let's keep it simple unless there is real reason to warn twice. > > > > zhaogongyi, > > Please note that I already applied the patches to linux-kselftest next for my > second pull request before the merge window. Please send the change > David requested in a separate patch on top of next as a fix. > > thanks, > -- Shuah

3 years, 1 month

1
0
0 0

[PATCH v2 0/6] Add _opts variant for bpf_*_get_fd_by_id()

by Roberto Sassu

From: Roberto Sassu <roberto.sassu(a)huawei.com> Add the _opts variant for bpf_*_get_fd_by_id() functions, to be able to pass to the kernel more options, when requesting a fd of an eBPF object. Pass the options through a newly introduced structure, bpf_get_fd_by_id_opts, which currently contains open_flags (the other two members are for compatibility and for padding). open_flags allows the caller to request specific permissions to access a map (e.g. read-only). This is useful for example in the situation where a map is write-protected. Besides patches 2-6, which introduce the new variants and the data structure, patch 1 fixes the LIBBPF_1.0.0 declaration in libbpf.map. Changelog v1: - Don't CC stable kernel mailing list for patch 1 (suggested by Andrii) - Rename bpf_get_fd_opts struct to bpf_get_fd_by_id_opts (suggested by Andrii) - Move declaration of _opts variants after non-opts variants (suggested by Andrii) - Correctly initialize bpf_map_info, fix style issues, use map from skeleton, check valid fd in the test (suggested by Andrii) - Rename libbpf_get_fd_opts test to libbpf_get_fd_by_id_opts Roberto Sassu (6): libbpf: Fix LIBBPF_1.0.0 declaration in libbpf.map libbpf: Introduce bpf_get_fd_by_id_opts and bpf_map_get_fd_by_id_opts() libbpf: Introduce bpf_prog_get_fd_by_id_opts() libbpf: Introduce bpf_btf_get_fd_by_id_opts() libbpf: Introduce bpf_link_get_fd_by_id_opts() selftests/bpf: Add tests for _opts variants of bpf_*_get_fd_by_id() tools/lib/bpf/bpf.c | 48 +++++++++- tools/lib/bpf/bpf.h | 16 ++++ tools/lib/bpf/libbpf.map | 6 +- tools/testing/selftests/bpf/DENYLIST.s390x | 1 + .../bpf/prog_tests/libbpf_get_fd_by_id_opts.c | 87 +++++++++++++++++++ .../bpf/progs/test_libbpf_get_fd_by_id_opts.c | 36 ++++++++ 6 files changed, 189 insertions(+), 5 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/libbpf_get_fd_by_id_opts.c create mode 100644 tools/testing/selftests/bpf/progs/test_libbpf_get_fd_by_id_opts.c -- 2.25.1

3 years, 1 month

3
9
0 0

Re: [PATCH -next v5 2/4] selftests/memory-hotplug: Restore memory before exit

by zhaogongyi

Hi! > > On 30.09.22 10:52, zhaogongyi wrote: > > Hi! > > > >> > >> On 30.09.22 08:35, Zhao Gongyi wrote: > >>> Some momory will be left in offline state when calling > >>> offline_memory_expect_fail() failed. Restore it before exit. > >>> > >>> Signed-off-by: Zhao Gongyi <zhaogongyi(a)huawei.com> > >>> --- > >>> .../memory-hotplug/mem-on-off-test.sh | 21 > >> ++++++++++++++----- > >>> 1 file changed, 16 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh > >> b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh > >>> index 1d87611a7d52..91a7457616bb 100755 > >>> --- a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh > >>> +++ b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh > >>> @@ -134,6 +134,16 @@ offline_memory_expect_fail() > >>> return 0 > >>> } > >>> > >>> +online_all_offline_memory() > >>> +{ > >>> + for memory in `hotpluggable_offline_memory`; do > >>> + if ! online_memory_expect_success $memory; then > >>> + echo "$FUNCNAME $memory: unexpected fail" >&2 > >> > >> Do we need that output? > > > > In my opinion, if online a memory node failed ,it should be a kernel bug > catched, so, I think the output here is needed. > > But online_memory_expect_success() already prints a warning, no? Yes, online_memory_expect_success() already prints a warning, remove the warning in online_all_offline_memory() seems ok, My previous consideration was that one more log information would make it easier to locate the wrong location. Best Regards, Gongyi

3 years, 1 month

3
2
0 0

[PATCH bpf-next 0/5] Fix bugs found by ASAN when running selftests

by Xu Kuohai

From: Xu Kuohai <xukuohai(a)huawei.com> Xu Kuohai (5): libbpf: Fix use-after-free in btf_dump_name_dups libbpf: Fix memory leak in parse_usdt_arg() selftests/bpf: Fix memory leak caused by not destroying skeleton selftest/bpf: Fix memory leak in kprobe_multi_test selftest/bpf: Fix error usage of ASSERT_OK in xdp_adjust_tail.c tools/lib/bpf/btf_dump.c | 47 +++++++++++---- tools/lib/bpf/usdt.c | 59 +++++++++++-------- .../selftests/bpf/prog_tests/bpf_iter.c | 4 +- .../bpf/prog_tests/kprobe_multi_test.c | 17 +++--- .../selftests/bpf/prog_tests/map_kptr.c | 3 +- .../selftests/bpf/prog_tests/tracing_struct.c | 3 +- .../bpf/prog_tests/xdp_adjust_tail.c | 6 +- 7 files changed, 88 insertions(+), 51 deletions(-) -- 2.25.1

3 years, 1 month

2
6
0 0

[PATCH bpf v2 0/5] Fix bugs found by ASAN when running selftests

by Xu Kuohai

v2: - Rebase and fix conflict v1: https://lore.kernel.org/bpf/20221009131830.395569-1-xukuohai@huaweicloud.co… Xu Kuohai (5): libbpf: Fix use-after-free in btf_dump_name_dups libbpf: Fix memory leak in parse_usdt_arg() selftests/bpf: Fix memory leak caused by not destroying skeleton selftest/bpf: Fix memory leak in kprobe_multi_test selftest/bpf: Fix error usage of ASSERT_OK in xdp_adjust_tail.c tools/lib/bpf/btf_dump.c | 47 +++++++++++---- tools/lib/bpf/usdt.c | 59 +++++++++++-------- .../bpf/prog_tests/kprobe_multi_test.c | 17 +++--- .../selftests/bpf/prog_tests/map_kptr.c | 3 +- .../selftests/bpf/prog_tests/tracing_struct.c | 3 +- .../bpf/prog_tests/xdp_adjust_tail.c | 6 +- 6 files changed, 85 insertions(+), 50 deletions(-) -- 2.30.2

3 years, 1 month

1
5
0 0

[RESEND PATCH] selftests/kexec: fix build for ARCH=x86_64

by Ricardo Cañuelo

Handle the scenario where the build is launched with the ARCH envvar defined as x86_64. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo(a)collabora.com> --- tools/testing/selftests/kexec/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/kexec/Makefile b/tools/testing/selftests/kexec/Makefile index 806a150648c3..67fe7a46cb62 100644 --- a/tools/testing/selftests/kexec/Makefile +++ b/tools/testing/selftests/kexec/Makefile @@ -1,10 +1,10 @@ # SPDX-License-Identifier: GPL-2.0-only # Makefile for kexec tests -uname_M := $(shell uname -m 2>/dev/null || echo not) -ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/) +ARCH ?= $(shell uname -m 2>/dev/null || echo not) +ARCH_PROCESSED := $(shell echo $(ARCH) | sed -e s/i.86/x86/ -e s/x86_64/x86/) -ifeq ($(ARCH),$(filter $(ARCH),x86 ppc64le)) +ifeq ($(ARCH_PROCESSED),$(filter $(ARCH_PROCESSED),x86 ppc64le)) TEST_PROGS := test_kexec_load.sh test_kexec_file_load.sh TEST_FILES := kexec_common_lib.sh -- 2.25.1

3 years, 1 month

1
0
0 0

[RESEND PATCH] selftests/intel_pstate: fix build for ARCH=x86_64

by Ricardo Cañuelo

Handle the scenario where the build is launched with the ARCH envvar defined as x86_64. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo(a)collabora.com> --- tools/testing/selftests/intel_pstate/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/intel_pstate/Makefile b/tools/testing/selftests/intel_pstate/Makefile index 39f0fa2a8fd6..05d66ef50c97 100644 --- a/tools/testing/selftests/intel_pstate/Makefile +++ b/tools/testing/selftests/intel_pstate/Makefile @@ -2,10 +2,10 @@ CFLAGS := $(CFLAGS) -Wall -D_GNU_SOURCE LDLIBS += -lm -uname_M := $(shell uname -m 2>/dev/null || echo not) -ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/) +ARCH ?= $(shell uname -m 2>/dev/null || echo not) +ARCH_PROCESSED := $(shell echo $(ARCH) | sed -e s/i.86/x86/ -e s/x86_64/x86/) -ifeq (x86,$(ARCH)) +ifeq (x86,$(ARCH_PROCESSED)) TEST_GEN_FILES := msr aperf endif -- 2.25.1

3 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror