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

[PATCH] kselftest: runner: fix TAP output for skipped tests

by Paolo Bonzini

According to the TAP specification, a skipped test must be marked as "ok" and annotated with the SKIP directive, for example ok 23 # skip Insufficient flogiston pressure. (https://testanything.org/tap-specification.html) Fix the runner script to match this. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- tools/testing/selftests/kselftest/runner.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/kselftest/runner.sh b/tools/testing/selftests/kselftest/runner.sh index 676b3a8b114d..f4815cbcd60f 100644 --- a/tools/testing/selftests/kselftest/runner.sh +++ b/tools/testing/selftests/kselftest/runner.sh @@ -77,7 +77,7 @@ run_one() echo "ok $test_num $TEST_HDR_MSG") || (rc=$?; \ if [ $rc -eq $skip_rc ]; then \ - echo "not ok $test_num $TEST_HDR_MSG # SKIP" + echo "ok $test_num $TEST_HDR_MSG # SKIP" elif [ $rc -eq $timeout_rc ]; then \ echo "#" echo "not ok $test_num $TEST_HDR_MSG # TIMEOUT" -- 2.26.2

5 years, 4 months

3
5
0 0

Re: [PATCH] selftests/exec: Add binfmt_script regression test

by Kees Cook

On Mon, Jun 15, 2020 at 03:41:54PM +0000, patchwork-bot+linux-kselftest(a)kernel.org wrote: > Hello: > > This patch was applied to shuah/linux-kselftest.git (refs/heads/next). Hi! Thanks for snagging this, however, see below... > > On Wed, 20 May 2020 02:05:56 -0700 you wrote: > > While working on commit b5372fe5dc84 ("exec: load_script: Do not exec > > truncated interpreter path"), I wrote a series of test scripts to verify > > corner cases. However, soon after, commit 6eb3c3d0a52d ("exec: increase > > BINPRM_BUF_SIZE to 256") landed, resulting in the tests needing to be > > refactored for the larger BINPRM_BUF_SIZE, which got lost on my TODO > > list. During the recent exec refactoring work[1], the need for these tests > > resurfaced, so I've finished them up for addition to the kernel selftests. > > > > [...] > > > Here is a summary with links: > - selftests/exec: Add binfmt_script regression test > https://git.kernel.org/shuah/linux-kselftest/c/b081320f0693cce0394f7c8bad9f… > > You are awesome, thank you! This was already picked up by Eric for this execve series, and has already landed in Linus's tree as b081320f0693cce0394f7c8bad9fba0b25982186 -- Kees Cook

5 years, 4 months

1
0
0 0

[PATCH 0/3] selftests/livepatch: small script cleanups

by Joe Lawrence

This is a small collection of tweaks for the shellscript side of the livepatch tests. If anyone else has a small cleanup (or even just a suggestion for a low-hanging change) and would like to tack it onto the set, let me know. based-on: livepatching.git, for-5.9/selftests-cleanup merge-thru: livepatching.git Joe Lawrence (3): selftests/livepatch: Don't clear dmesg when running tests selftests/livepatch: use $(dmesg --notime) instead of manually filtering selftests/livepatch: filter 'taints' from dmesg comparison tools/testing/selftests/livepatch/README | 16 +++--- .../testing/selftests/livepatch/functions.sh | 16 +++++- .../selftests/livepatch/test-callbacks.sh | 55 ++++--------------- .../selftests/livepatch/test-ftrace.sh | 5 +- .../selftests/livepatch/test-livepatch.sh | 15 +---- .../selftests/livepatch/test-shadow-vars.sh | 5 +- .../testing/selftests/livepatch/test-state.sh | 20 ++----- 7 files changed, 43 insertions(+), 89 deletions(-) -- 2.21.3

5 years, 4 months

4
17
0 0

[PATCH 16/29] 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

5 years, 4 months

1
0
0 0

[RFC,net-next, 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 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 [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 | 37 ++ net/l3mdev/l3mdev.c | 95 ++++ .../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

5 years, 4 months

5
17
0 0

Re: [RFC,net-next, 0/5] Strict mode for VRF

by David Ahern

On 6/13/20 4:39 PM, Dinesh Dutt wrote: > Understand Andrea. I guess I didn't say it well. What I meant to say was > that the strict mode is the default expected behavior in a classical router. > it has to be off by default for backwards compatibility.

5 years, 4 months

1
0
0 0

[PATCH 0/7] selftests/harness: Switch to TAP output

by Kees Cook

Hi, I finally got around to converting the kselftest_harness.h API to actually use the kselftest.h API so all the tools using it can actually report TAP correctly. As part of this, there are a bunch of related cleanups, API updates, and additions. Thanks! -Kees Kees Cook (7): selftests/clone3: Reorder reporting output selftests: Remove unneeded selftest API headers selftests/binderfs: Fix harness API usage selftests: Add header documentation and helpers selftests/harness: Switch to TAP output selftests/harness: Fully track XFAIL reports selftests/harness: Display signed values correctly tools/testing/selftests/clone3/clone3.c | 2 +- .../selftests/clone3/clone3_clear_sighand.c | 3 +- .../testing/selftests/clone3/clone3_set_tid.c | 2 +- .../filesystems/binderfs/binderfs_test.c | 284 +++++++++--------- tools/testing/selftests/kselftest.h | 78 ++++- tools/testing/selftests/kselftest_harness.h | 142 ++++++--- .../pid_namespace/regression_enomem.c | 1 - .../selftests/pidfd/pidfd_getfd_test.c | 1 - .../selftests/pidfd/pidfd_setns_test.c | 1 - .../selftests/uevent/uevent_filtering.c | 1 - 10 files changed, 330 insertions(+), 185 deletions(-) -- 2.25.1

5 years, 4 months

2
11
0 0

[PATCH] kunit: show error if kunit results are not present

by Uriel Guajardo

From: Uriel Guajardo <urielguajardo(a)google.com> Currently, if the kernel is configured incorrectly or if it crashes before any kunit tests are run, kunit finishes without error, reporting that 0 test cases were run. To fix this, an error is shown when the tap header is not found, which indicates that kunit was not able to run at all. Signed-off-by: Uriel Guajardo <urielguajardo(a)google.com> --- tools/testing/kunit/kunit_parser.py | 8 ++++---- tools/testing/kunit/kunit_tool_test.py | 11 +++++++++++ .../kunit/test_data/test_insufficient_memory.log | Bin 0 -> 856 bytes 3 files changed, 15 insertions(+), 4 deletions(-) create mode 100644 tools/testing/kunit/test_data/test_insufficient_memory.log diff --git a/tools/testing/kunit/kunit_parser.py b/tools/testing/kunit/kunit_parser.py index 64aac9dcd431..f13e0c0d6663 100644 --- a/tools/testing/kunit/kunit_parser.py +++ b/tools/testing/kunit/kunit_parser.py @@ -265,11 +265,9 @@ def bubble_up_suite_errors(test_suite_list: List[TestSuite]) -> TestStatus: return bubble_up_errors(lambda x: x.status, test_suite_list) def parse_test_result(lines: List[str]) -> TestResult: - if not lines: - return TestResult(TestStatus.NO_TESTS, [], lines) consume_non_diagnositic(lines) - if not parse_tap_header(lines): - return None + if not lines or not parse_tap_header(lines): + return TestResult(TestStatus.NO_TESTS, [], lines) test_suites = [] test_suite = parse_test_suite(lines) while test_suite: @@ -282,6 +280,8 @@ def parse_run_tests(kernel_output) -> TestResult: failed_tests = 0 crashed_tests = 0 test_result = parse_test_result(list(isolate_kunit_output(kernel_output))) + if test_result.status == TestStatus.NO_TESTS: + print_with_timestamp(red('[ERROR] ') + 'no kunit output detected') for test_suite in test_result.suites: if test_suite.status == TestStatus.SUCCESS: print_suite_divider(green('[PASSED] ') + test_suite.name) diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py index 984588d6ba95..4a7ef2eef831 100755 --- a/tools/testing/kunit/kunit_tool_test.py +++ b/tools/testing/kunit/kunit_tool_test.py @@ -170,6 +170,17 @@ class KUnitParserTest(unittest.TestCase): result.status) file.close() + def test_no_kunit_output(self): + crash_log = get_absolute_path( + 'test_data/test_insufficient_memory.log') + file = open(crash_log) + print_mock = mock.patch('builtins.print').start() + result = kunit_parser.parse_run_tests( + kunit_parser.isolate_kunit_output(file.readlines())) + print_mock.assert_any_call(StrContains("no kunit output detected")) + print_mock.stop() + file.close() + def test_crashed_test(self): crashed_log = get_absolute_path( 'test_data/test_is_test_passed-crash.log') diff --git a/tools/testing/kunit/test_data/test_insufficient_memory.log b/tools/testing/kunit/test_data/test_insufficient_memory.log new file mode 100644 index 0000000000000000000000000000000000000000..6c9e4da7b6d763a03c0c83302b2faa6dc21a6ea6 GIT binary patch literal 856 zcmbu6Piw<448`yH6xx0L3mw^@hf#VOv}5$J+fZ#KHj8CrJK6H>=Z2=CgO$<hA}n~n z_av{ZCy=#qP-&xMfG4=6vR)i)5n%+={(WUX@f3QQc$@8JeI=@sWh+JEQ*#MXVFVXF z3Ic%)LLrv~p$(Btnp72VZT95Dcs$;|{9!uqlCTqzsVj`yGB}JvL1F#T<`SpJ4?L6& zvLJa#bUk?B5jWafHpCGc^cwdSg)SXJ+Sp0$Q$V&%X;`!D6P@>grwf=!Y9>J$&;ioE z(YWH`vCdK5Yv8@UZFe8*_w@>lK?j;o`2XCkM`zDc9)5TBu*ma#3i~#uEu#ge+Mv@N z!H}`OJ&aI@v}o*ZK;I-rL20Tal*zuYY-cSL^z~bR2OA<uaygqX^7-Rzeh;N?h?hs> F><3Em&*A_8 literal 0 HcmV?d00001 -- 2.27.0.278.ge193c7cf3a9-goog

5 years, 4 months

2
2
0 0

[PATCH v2 0/1] selftests: fpga: dfl: A test for afu interrupt support

by trix＠redhat.com

From: Tom Rix <trix(a)redhat.com> repo: linux-next tag: next-20200611 Start applying selftests to drivers/fpga. While testing out this upcoming change on linux-fpga 'Add interrupt support to FPGA DFL drivers' I did not see any existing fpga tests. So I added one. Change from v1 Use ksft_* functions for reporting Tom Rix (1): selftests: fpga: dfl: A test for afu interrupt support tools/testing/selftests/Makefile | 1 + tools/testing/selftests/drivers/fpga/Makefile | 9 +++++ .../testing/selftests/drivers/fpga/afu_intr.c | 33 +++++++++++++++++++ tools/testing/selftests/drivers/fpga/config | 1 + 4 files changed, 44 insertions(+) create mode 100644 tools/testing/selftests/drivers/fpga/Makefile create mode 100644 tools/testing/selftests/drivers/fpga/afu_intr.c create mode 100644 tools/testing/selftests/drivers/fpga/config -- 2.18.1

5 years, 4 months

1
1
0 0

[PATCH v4 0/4] Fix some issues about kmod

by Tiezhu Yang

v4: - update the commit message with application of patch 3/4 v3: - use the quotes with correct format in the commit message of patch 4/4, sorry for that v2: - update the commit message to explain the detailed reason of patch 3/4 - add this cover letter Tiezhu Yang (4): selftests: kmod: Use variable NAME in kmod_test_0001() kmod: Remove redundant "be an" in the comment kmod: Return directly if module name is empty in request_module() test_kmod: Avoid potential double free in trigger_config_run_type() kernel/kmod.c | 10 +++++++--- lib/test_kmod.c | 2 +- tools/testing/selftests/kmod/kmod.sh | 4 ++-- 3 files changed, 10 insertions(+), 6 deletions(-) -- 2.1.0

5 years, 4 months

2
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror