June 2020 - Linux-kselftest-mirror

RFC: KTAP documentation - expected messages

by Frank Rowand

Tim Bird started a thread [1] proposing that he document the selftest result format used by Linux kernel tests. [1] https://lore.kernel.org/r/CY4PR13MB1175B804E31E502221BC8163FD830@CY4PR13MB1… The issue of messages generated by the kernel being tested (that are not messages directly created by the tests, but are instead triggered as a side effect of the test) came up. In this thread, I will call these messages "expected messages". Instead of sidetracking that thread with a proposal to handle expected messages, I am starting this new thread. I implemented an API for expected messages that are triggered by tests in the Devicetree unittest code, with the expectation that the specific details may change when the Devicetree unittest code adapts the KUnit API. It seems appropriate to incorporate the concept of expected messages in Tim's documentation instead of waiting to address the subject when the Devicetree unittest code adapts the KUnit API, since Tim's document may become the kernel selftest standard. Instead of creating a very long email containing multiple objects, I will reply to this email with a separate reply for each of: The "expected messages" API implemention and use can be from drivers/of/unittest.c in the mainline kernel. of_unittest_expect - A proof of concept perl program to filter console output containing expected messages output of_unittest_expect is also available by cloning https://github.com/frowand/dt_tools.git An example raw console output with timestamps and expect messages. An example of console output processed by filter program of_unittest_expect to be more human readable. The expected messages are not removed, but are flagged. An example of console output processed by filter program of_unittest_expect to be more human readable. The expected messages are removed instead of being flagged.

4 years, 1 month

5
12
0 0

[RESEND PATCH 0/3] selftests: lib.mk improvements

by Yauheni Kaliuta

Fix make[1]: execvp: /bin/sh: Argument list too long encountered with some shells and a couple of more potential problems in that part of code. Yauheni Kaliuta (3): selftests: do not use .ONESHELL selftests: fix condition in run_tests selftests: simplify run_tests tools/testing/selftests/lib.mk | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) -- 2.26.2

4 years, 1 month

2
5
0 0

[PATCH v2 09/15] selftests/vm/keys: fix a broken reference at protection_keys.c

by Mauro Carvalho Chehab

Changeset 1eecbcdca2bd ("docs: move protection-keys.rst to the core-api book") from Jun 7, 2019 converted protection-keys.txt file to ReST. A recent change at protection_keys.c partially reverted such changeset, causing it to point to a non-existing file: - * Tests x86 Memory Protection Keys (see Documentation/core-api/protection-keys.rst) + * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt) It sounds to me that the changeset that introduced such change 4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name") could also have other side effects, as it sounds that it was not generated against uptream code, but, instead, against a version older than Jun 7, 2019. Fixes: 4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- tools/testing/selftests/vm/protection_keys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c index fc19addcb5c8..fdbb602ecf32 100644 --- a/tools/testing/selftests/vm/protection_keys.c +++ b/tools/testing/selftests/vm/protection_keys.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt) + * Tests Memory Protection Keys (see Documentation/core-api/protection-keys.rst) * * There are examples in here of: * * how to set protection keys on memory -- 2.26.2

4 years, 1 month

1
0
0 0

RFC - kernel selftest result documentation (KTAP)

by Bird, Tim

Some months ago I started work on a document to formalize how kselftest implements the TAP specification. However, I didn't finish that work. Maybe it's time to do so now. kselftest has developed a few differences from the original TAP specification, and some extensions that I believe are worth documenting. Essentially, we have created our own KTAP (kernel TAP) format. I think it is worth documenting our conventions, in order to keep everyone on the same page. Below is a partially completed document on my understanding of KTAP, based on examination of some of the kselftest test output. I have not reconciled this with the kunit output format, which I believe has some differences (which maybe we should resolve before we get too far into this). I submit the document now, before it is finished, because a patch was recently introduced to alter one of the result conventions (from SKIP='not ok' to SKIP='ok'). See the document include inline below ====== start of ktap-doc-rfc.txt ====== Selftest preferred output format -------------------------------- The linux kernel selftest system uses TAP (Test Anything Protocol) output to make testing results consumable by automated systems. A number of Continuous Integration (CI) systems test the kernel every day. It is useful for these systems that output from selftest programs be consistent and machine-parsable. At the same time, it is useful for test results to be human-readable as well. The kernel test result format is based on a variation TAP TAP is a simple text-based format that is documented on the TAP home page (http://testanything.org/). There is an official TAP13 specification here: http://testanything.org/tap-version-13-specification.html The kernel test result format consists of 5 major elements, 4 of which are line-based: * the output version line * the plan line * one or more test result lines (also called test result lines) * a possible "Bail out!" line optional elements: * diagnostic data The 5th element is diagnostic information, which is used to describe items running in the test, and possibly to explain test results. A sample test result is show below: Some other lines may be placed the test harness, and are not emitted by individual test programs: * one or more test identification lines * a possible results summary line Here is an example: TAP version 13 1..1 # selftests: cpufreq: main.sh # pid 8101's current affinity mask: fff # pid 8101's new affinity mask: 1 ok 1 selftests: cpufreq: main.sh The output version line is: "TAP version 13" The test plan is "1..1". Element details =============== Output version line ------------------- The output version line is always "TAP version 13". Although the kernel test result format has some additions to the TAP13 format, the version line reported by kselftest tests is (currently) always the exact string "TAP version 13" This is always the first line of test output. Test plan line -------------- The test plan indicates the number of individual test cases intended to be executed by the test. It always starts with "1.." and is followed by the number of tests cases. In the example above, 1..1", indicates that this test reports only 1 test case. The test plan line can be placed in two locations: * the second line of test output, when the number of test cases is known in advance * as the last line of test output, when the number of test cases is not known in advance. Most often, the number of test cases is known in advance, and the test plan line appears as the second line of test output, immediately following the output version line. The number of test cases might not be known in advance if the number of tests is calculated from runtime data. In this case, the test plan line is emitted as the last line of test output. Test result lines ----------------- The test output consists of one or more test result lines that indicate the actual results for the test. These have the format: <result> <number> <description> [<directive>] [<diagnostic data>] The ''result'' must appear at the start of a line (except for when a test is nested, see below), and must consist of one of the following two phrases: * ok * not ok If the test passed, then the result is reported as "ok". If the test failed, then the result is reported as "not ok". These must be in lower case, exactly as shown. The ''number'' in the test result line represents the number of the test case being performed by the test program. This is often used by test harnesses as a unique identifier for each test case. The test number is a base-10 number, starting with 1. It should increase by one for each new test result line emitted. If possible the number for a test case should be kept the same over the lifetime of the test. The ''description'' is a short description of the test case. This can be any string of words, but should avoid using colons (':') except as part of a fully qualifed test case name (see below). Finally, it is possible to use a test directive to indicate another possible outcome for a test: that it was skipped. To report that a test case was skipped, the result line should start with the result "not ok", and the directive "# SKIP" should be placed after the test description. (Note that this deviates from the TAP13 specification). A test may be skipped for a variety of reasons, ranging for insufficient privileges to missing features or resources required to execute that test case. It is usually helpful if a diagnostic message is emitted to explain the reasons for the skip. If the message is a single line and is short, the diagnostic message may be placed after the '# SKIP' directive on the same line as the test result. However, if it is not on the test result line, it should precede the test line (see diagnostic data, next). Diagnostic data --------------- Diagnostic data is text that reports on test conditions or test operations, or that explains test results. In the kernel test result format, diagnostic data is placed on lines that start with a hash sign, followed by a space ('# '). One special format of diagnostic data is a test identification line, that has the fully qualified name of a test case. Such a test identification line marks the start of test output for a test case. In the example above, there are three lines that start with '#' which precede the test result line: # selftests: cpufreq: main.sh # pid 8101's current affinity mask: fff # pid 8101's new affinity mask: 1 These are used to indicate diagnostic data for the test case 'selftests: cpufreq: main.sh' Material in comments between the identification line and the test result line are diagnostic data that can help to interpret the results of the test. The TAP specification indicates that automated test harnesses may ignore any line that is not one of the mandatory prescribed lines (that is, the output format version line, the plan line, a test result line, or a "Bail out!" line.) Bail out! --------- If a line in the test output starts with 'Bail out!', it indicates that the test was aborted for some reason. It indicates that the test is unable to proceed, and no additional tests will be performed. This can be used at the very beginning of a test, or anywhere in the middle of the test, to indicate that the test can not continue. --- from here on is not-yet-organized material Tip: - don't change the test plan based on skipped tests. - it is better to report that a test case was skipped, than to not report it - that is, don't adjust the number of test cases based on skipped tests Other things to mention: TAP13 elements not used: - yaml for diagnostic messages - reason: try to keep things line-based, since output from other things may be interspersed with messages from the test itself - TODO directive KTAP Extensions beyond TAP13: - nesting - via indentation - indentation makes it easier for humans to read - test identifier - multiple parts, separated by ':' - summary lines - can be skipped by CI systems that do their own calculations Other notes: - automatic assignment of result status based on exit code Tips: - do NOT describe the result in the test line - the test case description should be the same whether the test succeeds or fails - use diagnostic lines to describe or explain results, if this is desirable - test numbers are considered harmful - test harnesses should use the test description as the identifier - test numbers change when testcases are added or removed - which means that results can't be compared between different versions of the test - recommendations for diagnostic messages: - reason for failure - reason for skip - diagnostic data should always preceding the result line - problem: harness may emit result before test can do assessment to determine reason for result - this is what the kernel uses Differences between kernel test result format and TAP13: - in KTAP the "# SKIP" directive is placed after the description on the test result line ====== start of ktap-doc-rfc.txt ====== OK - that's the end of the RFC doc. Here are a few questions: - is this document desired or not? - is it too long or too short? - if the document is desired, where should it be placed? I assume somewhere under Documentation, and put into .rst format. Suggestions for a name and location are welcome. - is this document accurate? I think KUNIT does a few things differently than this description. - is the intent to have kunit and kselftest have the same output format? if so, then these should be rationalized. Finally, - Should a SKIP result be 'ok' (TAP13 spec) or 'not ok' (current kselftest practice)? See https://testanything.org/tap-version-13-specification.html Regards, -- Tim

4 years, 1 month

6
42
0 0

[PATCH 00/16] mm/hmm/nouveau: THP mapping and migration

by Ralph Campbell

These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM self tests. Patch 7-8 prepare nouveau for the meat of this series which adds support and testing for compound page mapping of system memory (patches 9-11) and compound page migration to device private memory (patches 12-16). Since these changes are split across mm core, nouveau, and testing, I'm guessing Jason Gunthorpe's HMM tree would be appropriate. Ralph Campbell (16): mm: fix migrate_vma_setup() src_owner and normal pages nouveau: fix migrate page regression nouveau: fix mixed normal and device private page migration mm/hmm: fix test timeout on slower machines mm/hmm/test: remove redundant page table invalidate mm/hmm: test mixed normal and device private migrations nouveau: make nvkm_vmm_ctor() and nvkm_mmu_ptp_get() static nouveau/hmm: fault one page at a time mm/hmm: add output flag for compound page mapping nouveau/hmm: support mapping large sysmem pages hmm: add tests for HMM_PFN_COMPOUND flag mm/hmm: optimize migrate_vma_setup() for holes mm: support THP migration to device private memory mm/thp: add THP allocation helper mm/hmm/test: add self tests for THP migration nouveau: support THP migration to private memory drivers/gpu/drm/nouveau/nouveau_dmem.c | 177 +++++--- drivers/gpu/drm/nouveau/nouveau_svm.c | 241 +++++------ drivers/gpu/drm/nouveau/nouveau_svm.h | 3 +- .../gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +- .../gpu/drm/nouveau/nvkm/subdev/mmu/priv.h | 2 + drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 10 +- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 - .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 29 +- include/linux/gfp.h | 10 + include/linux/hmm.h | 4 +- include/linux/migrate.h | 1 + include/linux/mm.h | 1 + lib/test_hmm.c | 359 ++++++++++++---- lib/test_hmm_uapi.h | 2 + mm/hmm.c | 10 +- mm/huge_memory.c | 46 ++- mm/internal.h | 1 - mm/memory.c | 10 +- mm/memremap.c | 9 +- mm/migrate.c | 236 +++++++++-- mm/page_alloc.c | 1 + tools/testing/selftests/vm/hmm-tests.c | 388 +++++++++++++++++- 22 files changed, 1203 insertions(+), 346 deletions(-) -- 2.20.1

4 years, 1 month

6
37
0 0

[PATCH] kselftest: ksft_test_num return type should be unsigned

by Paolo Bonzini

Fixes a compiler warning: In file included from sync_test.c:37: ../kselftest.h: In function ‘ksft_print_cnts’: ../kselftest.h:78:16: warning: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare] if (ksft_plan != ksft_test_num()) ^~ Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- tools/testing/selftests/kselftest.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/kselftest.h b/tools/testing/selftests/kselftest.h index 0ac49d91a260..862eee734553 100644 --- a/tools/testing/selftests/kselftest.h +++ b/tools/testing/selftests/kselftest.h @@ -36,7 +36,7 @@ struct ksft_count { static struct ksft_count ksft_cnt; static unsigned int ksft_plan; -static inline int ksft_test_num(void) +static inline unsigned int ksft_test_num(void) { return ksft_cnt.ksft_pass + ksft_cnt.ksft_fail + ksft_cnt.ksft_xfail + ksft_cnt.ksft_xpass + -- 2.26.2

4 years, 1 month

1
0
0 0

Re: mmotm 2020-06-20-21-36 uploaded (lkdtm/bugs.c)

by Randy Dunlap

On 6/20/20 9:37 PM, akpm(a)linux-foundation.org wrote: > The mm-of-the-moment snapshot 2020-06-20-21-36 has been uploaded to > > http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. drivers/misc/lkdtm/bugs.c has build errors when building UML for i386 (allmodconfig or allyesconfig): In file included from ../drivers/misc/lkdtm/bugs.c:17:0: ../arch/x86/um/asm/desc.h:7:0: warning: "LDT_empty" redefined #define LDT_empty(info) (\ In file included from ../arch/um/include/asm/mmu.h:10:0, from ../include/linux/mm_types.h:18, from ../include/linux/sched/signal.h:13, from ../drivers/misc/lkdtm/bugs.c:11: ../arch/x86/um/asm/mm_context.h:65:0: note: this is the location of the previous definition #define LDT_empty(info) (_LDT_empty(info)) ../drivers/misc/lkdtm/bugs.c: In function ‘lkdtm_DOUBLE_FAULT’: ../drivers/misc/lkdtm/bugs.c:428:9: error: variable ‘d’ has initializer but incomplete type struct desc_struct d = { ^~~~~~~~~~~ ../drivers/misc/lkdtm/bugs.c:429:4: error: ‘struct desc_struct’ has no member named ‘type’ .type = 3, /* expand-up, writable, accessed data */ ^~~~ ../drivers/misc/lkdtm/bugs.c:429:11: warning: excess elements in struct initializer .type = 3, /* expand-up, writable, accessed data */ ^ ../drivers/misc/lkdtm/bugs.c:429:11: note: (near initialization for ‘d’) ../drivers/misc/lkdtm/bugs.c:430:4: error: ‘struct desc_struct’ has no member named ‘p’ .p = 1, /* present */ ^ ../drivers/misc/lkdtm/bugs.c:430:8: warning: excess elements in struct initializer .p = 1, /* present */ ^ ../drivers/misc/lkdtm/bugs.c:430:8: note: (near initialization for ‘d’) ../drivers/misc/lkdtm/bugs.c:431:4: error: ‘struct desc_struct’ has no member named ‘d’ .d = 1, /* 32-bit */ ^ ../drivers/misc/lkdtm/bugs.c:431:8: warning: excess elements in struct initializer .d = 1, /* 32-bit */ ^ ../drivers/misc/lkdtm/bugs.c:431:8: note: (near initialization for ‘d’) ../drivers/misc/lkdtm/bugs.c:432:4: error: ‘struct desc_struct’ has no member named ‘g’ .g = 0, /* limit in bytes */ ^ ../drivers/misc/lkdtm/bugs.c:432:8: warning: excess elements in struct initializer .g = 0, /* limit in bytes */ ^ ../drivers/misc/lkdtm/bugs.c:432:8: note: (near initialization for ‘d’) ../drivers/misc/lkdtm/bugs.c:433:4: error: ‘struct desc_struct’ has no member named ‘s’ .s = 1, /* not system */ ^ ../drivers/misc/lkdtm/bugs.c:433:8: warning: excess elements in struct initializer .s = 1, /* not system */ ^ ../drivers/misc/lkdtm/bugs.c:433:8: note: (near initialization for ‘d’) ../drivers/misc/lkdtm/bugs.c:428:21: error: storage size of ‘d’ isn’t known struct desc_struct d = { ^ ../drivers/misc/lkdtm/bugs.c:437:2: error: implicit declaration of function ‘write_gdt_entry’; did you mean ‘init_wait_entry’? [-Werror=implicit-function-declaration] write_gdt_entry(get_cpu_gdt_rw(smp_processor_id()), ^~~~~~~~~~~~~~~ init_wait_entry ../drivers/misc/lkdtm/bugs.c:437:18: error: implicit declaration of function ‘get_cpu_gdt_rw’; did you mean ‘get_cpu_ptr’? [-Werror=implicit-function-declaration] write_gdt_entry(get_cpu_gdt_rw(smp_processor_id()), ^~~~~~~~~~~~~~ get_cpu_ptr ../drivers/misc/lkdtm/bugs.c:438:27: error: ‘DESCTYPE_S’ undeclared (first use in this function) GDT_ENTRY_TLS_MIN, &d, DESCTYPE_S); ^~~~~~~~~~ ../drivers/misc/lkdtm/bugs.c:438:27: note: each undeclared identifier is reported only once for each function it appears in ../drivers/misc/lkdtm/bugs.c:428:21: warning: unused variable ‘d’ [-Wunused-variable] struct desc_struct d = { ^ cc1: some warnings being treated as errors -- ~Randy Reported-by: Randy Dunlap <rdunlap(a)infradead.org>

4 years, 1 month

3
2
0 0

[PATCH] Documentation: kunit: Add naming guidelines

by David Gow

As discussed in [1], KUnit tests have hitherto not had a particularly consistent naming scheme. This adds documentation outlining how tests and test suites should be named, including how those names should be used in Kconfig entries and filenames. [1]: https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u Signed-off-by: David Gow <davidgow(a)google.com> --- This is a first draft of some naming guidelines for KUnit tests. Note that I haven't edited it for spelling/grammar/style yet: I wanted to get some feedback on the actual naming conventions first. The issues which came most to the forefront while writing it were: - Do we want to make subsystems a more explicit thing (make the KUnit framework recognise them, make suites KTAP subtests of them, etc) - I'm leaning towards no, mainly because it doesn't seem necessary, and it makes the subsystem-with-only-one-suite case ugly. - Do we want to support (or encourage) Kconfig options and/or modules at the subsystem level rather than the suite level? - This could be nice: it'd avoid the proliferation of a large number of tiny config options and modules, and would encourage the test for <module> to be <module>_kunit, without other stuff in-between. - As test names are also function names, it may actually make sense to decorate them with "test" or "kunit" or the like. - If we're testing a function "foo", "test_foo" seems like as good a name for the function as any. Sure, many cases may could have better names like "foo_invalid_context" or something, but that won't make sense for everything. - Alternatively, do we split up the test name and the name of the function implementing the test? Thoughts? Documentation/dev-tools/kunit/index.rst | 1 + Documentation/dev-tools/kunit/style.rst | 139 ++++++++++++++++++++++++ 2 files changed, 140 insertions(+) create mode 100644 Documentation/dev-tools/kunit/style.rst diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index e93606ecfb01..117c88856fb3 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel usage kunit-tool api/index + style faq What is KUnit? diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst new file mode 100644 index 000000000000..9363b5607262 --- /dev/null +++ b/Documentation/dev-tools/kunit/style.rst @@ -0,0 +1,139 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Test Style and Nomenclature +=========================== + +Subsystems, Suites, and Tests +============================= + +In order to make tests as easy to find as possible, they're grouped into suites +and subsystems. A test suite is a group of tests which test a related area of +the kernel, and a subsystem is a set of test suites which test different parts +of the same kernel subsystem or driver. + +Subsystems +---------- + +Every test suite must belong to a subsystem. A subsystem is a collection of one +or more KUnit test suites which test the same driver or part of the kernel. A +rule of thumb is that a test subsystem should match a single kernel module. If +the code being tested can't be compiled as a module, in many cases the subsystem +should correspond to a directory in the source tree or an entry in the +MAINTAINERS file. If unsure, follow the conventions set by tests in similar +areas. + +Test subsystems should be named after the code being tested, either after the +module (wherever possible), or after the directory or files being tested. Test +subsystems should be named to avoid ambiguity where necessary. + +If a test subsystem name has multiple components, they should be separated by +underscores. Do not include "test" or "kunit" directly in the subsystem name +unless you are actually testing other tests or the kunit framework itself. + +Example subsystems could be: + +* ``ext4`` +* ``apparmor`` +* ``kasan`` + +.. note:: + The KUnit API and tools do not explicitly know about subsystems. They're + simply a way of categorising test suites and naming modules which + provides a simple, consistent way for humans to find and run tests. This + may change in the future, though. + +Suites +------ + +KUnit tests are grouped into test suites, which cover a specific area of +functionality being tested. Test suites can have shared initialisation and +shutdown code which is run for all tests in the suite. +Not all subsystems will need to be split into multiple test suites (e.g. simple drivers). + +Test suites are named after the subsystem they are part of. If a subsystem +contains several suites, the specific area under test should be appended to the +subsystem name, separated by an underscore. + +The full test suite name (including the subsystem name) should be specified as +the ``.name`` member of the ``kunit_suite`` struct, and forms the base for the +module name (see below). + +Example test suites could include: + +* ``ext4_inode`` +* ``kunit_try_catch`` +* ``apparmor_property_entry`` +* ``kasan`` + +Tests +----- + +Individual tests consist of a single function which tests a constrained +codepath, property, or function. In the test output, individual tests' results +will show up as subtests of the suite's results. + +Tests should be named after what they're testing. This is often the name of the +function being tested, with a description of the input or codepath being tested. +As tests are C functions, they should be named and written in accordance with +the kernel coding style. + +.. note:: + As tests are themselves functions, their names cannot conflict with + other C identifiers in the kernel. This may require some creative + naming. It's a good idea to make your test functions `static` to avoid + polluting the global namespace. + +Should it be necessary to refer to a test outside the context of its test suite, +the *fully-qualified* name of a test should be the suite name followed by the +test name, separated by a colon (i.e. ``suite:test``). + +Test Kconfig Entries +==================== + +Every test suite should be tied to a Kconfig entry. + +This Kconfig entry must: + +* be named ``CONFIG_<name>_KUNIT_TEST``: where <name> is the name of the test + suite. +* be listed either alongside the config entries for the driver/subsystem being + tested, or be under [Kernel Hacking]→[Kernel Testing and Coverage] +* depend on ``CONFIG_KUNIT`` +* be visible only if ``CONFIG_KUNIT_ALL_TESTS`` is not enabled. +* have a default value of ``CONFIG_KUNIT_ALL_TESTS``. +* have a brief description of KUnit in the help text +* include "If unsure, say N" in the help text + +Unless there's a specific reason not to (e.g. the test is unable to be built as +a module), Kconfig entries for tests should be tristate. + +An example Kconfig entry: + +.. code-block:: none + + config FOO_KUNIT_TEST + tristate "KUnit test for foo" if !KUNIT_ALL_TESTS + depends on KUNIT + default KUNIT_ALL_TESTS + help + This builds unit tests for foo. + + For more information on KUnit and unit tests in general, please refer + to the KUnit documentation in Documentation/dev-tools/kunit + + If unsure, say N + + +Test Filenames +============== + +Where possible, test suites should be placed in a separate source file in the +same directory as the code being tested. + +This file should be named ``<suite>_kunit.c``. It may make sense to strip +excessive namespacing from the source filename (e.g., ``firmware_kunit.c`` instead of +``<drivername>_firmware.c``), but please ensure the module name does contain the +full suite name. + + -- 2.27.0.111.gc72c7da667-goog

4 years, 1 month

4
3
0 0

[PATCH] Revert "tpm: selftest: cleanup after unseal with wrong auth/policy test"

by Jarkko Sakkinen

The reverted commit illegitly uses tpm2-tools. External dependencies are absolutely forbidden from these tests. There is also the problem that clearing is not necessarily wanted behavior if the test/target computer is not used only solely for testing. Fixes: a9920d3bad40 ("tpm: selftest: cleanup after unseal with wrong auth/policy test") Cc: Tadeusz Struk <tadeusz.struk(a)intel.com> Cc: stable(a)vger.kernel.org Cc: linux-integrity(a)vger.kernel.org Cc: linux-kselftest(a)vger.kernel.org Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> --- tools/testing/selftests/tpm2/test_smoke.sh | 5 ----- 1 file changed, 5 deletions(-) diff --git a/tools/testing/selftests/tpm2/test_smoke.sh b/tools/testing/selftests/tpm2/test_smoke.sh index 663062701d5a..79f8e9da5d21 100755 --- a/tools/testing/selftests/tpm2/test_smoke.sh +++ b/tools/testing/selftests/tpm2/test_smoke.sh @@ -8,8 +8,3 @@ ksft_skip=4 python -m unittest -v tpm2_tests.SmokeTest python -m unittest -v tpm2_tests.AsyncTest - -CLEAR_CMD=$(which tpm2_clear) -if [ -n $CLEAR_CMD ]; then - tpm2_clear -T device -fi -- 2.25.1

4 years, 1 month

1
0
0 0

[net-next,v1,0/5] Strict mode for VRF

by Andrea Mayer

This patch set adds the new "strict mode" functionality to the Virtual Routing and Forwarding infrastructure (VRF). Hereafter we discuss the requirements and the main features of the "strict mode" for VRF. On VRF creation, it is necessary to specify the associated routing table used during the lookup operations. Currently, there is no mechanism that avoids creating multiple VRFs sharing the same routing table. In other words, it is not possible to force a one-to-one relationship between a specific VRF and the table associated with it. The "strict mode" imposes that each VRF can be associated to a routing table only if such routing table is not already in use by any other VRF. In particular, the strict mode ensures that: 1) given a specific routing table, the VRF (if exists) is uniquely identified; 2) given a specific VRF, the related table is not shared with any other VRF. Constraints (1) and (2) force a one-to-one relationship between each VRF and the corresponding routing table. The strict mode feature is designed to be network-namespace aware and it can be directly enabled/disabled acting on the "strict_mode" parameter. Read and write operations are carried out through the classic sysctl command on net.vrf.strict_mode path, i.e: sysctl -w net.vrf.strict_mode=1. Only two distinct values {0,1} are accepted by the strict_mode parameter: - with strict_mode=0, multiple VRFs can be associated with the same table. This is the (legacy) default kernel behavior, the same that we experience when the strict mode patch set is not applied; - with strict_mode=1, the one-to-one relationship between the VRFs and the associated tables is guaranteed. In this configuration, the creation of a VRF which refers to a routing table already associated with another VRF fails and the error is returned to the user. The kernel keeps track of the associations between a VRF and the routing table during the VRF setup, in the "management" plane. Therefore, the strict mode does not impact the performance or the intrinsic functionality of the data plane in any way. When the strict mode is active it is always possible to disable the strict mode, while the reverse operation is not always allowed. Setting the strict_mode parameter to 0 is equivalent to removing the one-to-one constraint between any single VRF and its associated routing table. Conversely, if the strict mode is disabled and there are multiple VRFs that refer to the same routing table, then it is prohibited to set the strict_mode parameter to 1. In this configuration, any attempt to perform the operation will lead to an error and it will be reported to the user. To enable strict mode once again (by setting the strict_mode parameter to 1), you must first remove all the VRFs that share common tables. There are several use cases which can take advantage from the introduction of the strict mode feature. In particular, the strict mode allows us to: i) guarantee the proper functioning of some applications which deal with routing protocols; ii) perform some tunneling decap operations which require to use specific routing tables for segregating and forwarding the traffic. Considering (i), the creation of different VRFs that point to the same table leads to the situation where two different routing entities believe they have exclusive access to the same table. This leads to the situation where different routing daemons can conflict for gaining routes control due to overlapping tables. By enabling strict mode it is possible to prevent this situation which often occurs due to incorrect configurations done by the users. The ability to enable/disable the strict mode functionality does not depend on the tool used for configuring the networking. In essence, the strict mode patch solves, at the kernel level, what some other patches [1] had tried to solve at the userspace level (using only iproute2) with all the related problems. Considering (ii), the introduction of the strict mode functionality allows us implementing the SRv6 End.DT4 behavior. Such behavior terminates a SR tunnel and it forwards the IPv4 traffic according to the routes present in the routing table supplied during the configuration. The SRv6 End.DT4 can be realized exploiting the routing capabilities made available by the VRF infrastructure. This behavior could leverage a specific VRF for forcing the traffic to be forwarded in accordance with the routes available in the VRF table. Anyway, in order to make the End.DT4 properly work, it must be guaranteed that the table used for the route lookup operations is bound to one and only one VRF. In this way, it is possible to use the table for uniquely retrieving the associated VRF and for routing packets. I would like to thank David Ahern for his constant and valuable support during the design and development phases of this patch set. Comments, suggestions and improvements are very welcome! Thanks, Andrea Mayer v1 l3mdev: add infrastructure for table to VRF mapping - define l3mdev_lock as static, thanks to Jakub Kicinski; - move lookup_by_table_id_t from l3mdev.c to l3mdev.h and update the l3mdev_dev_table_lookup_{un}register functions accordingly, thanks to David Ahern. vrf: track associations between VRF devices and tables - change shared_tables type from 'int' to 'u32', thanks to Stephen Hemminger and David Ahern; - update comments for share_tables. vrf: add sysctl parameter for strict mode - change type 'void __user *buffer' to 'void *buffer' in argument 3 of vrf_shared_table_handler function, thanks to Jakub Kicinski. [1] https://lore.kernel.org/netdev/20200307205916.15646-1-sharpd@cumulusnetwork… Andrea Mayer (5): l3mdev: add infrastructure for table to VRF mapping vrf: track associations between VRF devices and tables vrf: add sysctl parameter for strict mode vrf: add l3mdev registration for table to VRF device lookup selftests: add selftest for the VRF strict mode drivers/net/vrf.c | 450 +++++++++++++++++- include/net/l3mdev.h | 39 ++ net/l3mdev/l3mdev.c | 93 ++++ .../selftests/net/vrf_strict_mode_test.sh | 390 +++++++++++++++ 4 files changed, 963 insertions(+), 9 deletions(-) create mode 100755 tools/testing/selftests/net/vrf_strict_mode_test.sh -- 2.20.1

4 years, 1 month

3
7
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror June 2020