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

by David Gow

This patchset contains everything needed to integrate KASAN and KUnit. KUnit will be able to: (1) Fail tests when an unexpected KASAN error occurs (2) Pass tests when an expected KASAN error occurs Convert KASAN tests to KUnit with the exception of copy_user_test because KUnit is unable to test those. Add documentation on how to run the KASAN tests with KUnit and what to expect when running these tests. This patchset depends on: - "[PATCH v3 kunit-next 0/2] kunit: extend kunit resources API" [1] - "[PATCH v3 0/3] Fix some incompatibilites between KASAN and FORTIFY_SOURCE" [2] Changes from v6: - Rebased on top of kselftest/kunit - Rebased on top of Daniel Axtens' fix for FORTIFY_SOURCE incompatibilites [2] - Removed a redundant report_enabled() check. - Fixed some places with out of date Kconfig names in the documentation. Changes from v5: - Split out the panic_on_warn changes to a separate patch. - Fix documentation to fewer to the new Kconfig names. - Fix some changes which were in the wrong patch. - Rebase on top of kselftest/kunit (currently identical to 5.7-rc1) Changes from v4: - KASAN no longer will panic on errors if both panic_on_warn and kasan_multishot are enabled. - As a result, the KASAN tests will no-longer disable panic_on_warn. - This also means panic_on_warn no-longer needs to be exported. - The use of temporary "kasan_data" variables has been cleaned up somewhat. - A potential refcount/resource leak should multiple KASAN errors appear during an assertion was fixed. - Some wording changes to the KASAN test Kconfig entries. Changes from v3: - KUNIT_SET_KASAN_DATA and KUNIT_DO_EXPECT_KASAN_FAIL have been combined and included in KUNIT_DO_EXPECT_KASAN_FAIL() instead. - Reordered logic in kasan_update_kunit_status() in report.c to be easier to read. - Added comment to not use the name "kasan_data" for any kunit tests outside of KUNIT_EXPECT_KASAN_FAIL(). Changes since v2: - Due to Alan's changes in [1], KUnit can be built as a module. - The name of the tests that could not be run with KUnit has been changed to be more generic: test_kasan_module. - Documentation on how to run the new KASAN tests and what to expect when running them has been added. - Some variables and functions are now static. - Now save/restore panic_on_warn in a similar way to kasan_multi_shot and renamed the init/exit functions to be more generic to accommodate. - Due to [3] in kasan_strings, kasan_memchr, and kasan_memcmp will fail if CONFIG_AMD_MEM_ENCRYPT is enabled so return early and print message explaining this circumstance. - Changed preprocessor checks to C checks where applicable. Changes since v1: - Make use of Alan Maguire's suggestion to use his patch that allows static resources for integration instead of adding a new attribute to the kunit struct - All KUNIT_EXPECT_KASAN_FAIL statements are local to each test - The definition of KUNIT_EXPECT_KASAN_FAIL is local to the test_kasan.c file since it seems this is the only place this will be used. - Integration relies on KUnit being builtin - copy_user_test has been separated into its own file since KUnit is unable to test these. This can be run as a module just as before, using CONFIG_TEST_KASAN_USER - The addition to the current task has been separated into its own patch as this is a significant enough change to be on its own. [1] https://lore.kernel.org/linux-kselftest/1585313122-26441-1-git-send-email-a… [2] https://lkml.org/lkml/2020/4/23/708 [3] https://bugzilla.kernel.org/show_bug.cgi?id=206337 David Gow (1): mm: kasan: Do not panic if both panic_on_warn and kasan_multishot set Patricia Alfonso (4): Add KUnit Struct to Current Task KUnit: KASAN Integration KASAN: Port KASAN Tests to KUnit KASAN: Testing Documentation Documentation/dev-tools/kasan.rst | 70 +++ include/kunit/test.h | 5 + include/linux/kasan.h | 6 + include/linux/sched.h | 4 + lib/Kconfig.kasan | 18 +- lib/Makefile | 3 +- lib/kunit/test.c | 13 +- lib/test_kasan.c | 688 +++++++++++++----------------- lib/test_kasan_module.c | 76 ++++ mm/kasan/report.c | 34 +- 10 files changed, 514 insertions(+), 403 deletions(-) create mode 100644 lib/test_kasan_module.c -- 2.26.2.303.gf8c07b1a785-goog

5 years, 1 month

6
11
0 0

BUG: arch/x86/kvm/mmu/mmu.c:3722: kvm_mmu_load+0x407/0x420

by Naresh Kamboju

While running selftest kvm set_memory_region_test on x86_64 linux-next kernel 5.7.0-rc6-next-20200518 the kernel BUG noticed. steps to reproduce: (always reproducible ) ------------------------- cd /opt/kselftests/default-in-kernel/kvm ./set_memory_region_test BAD: next-20200518 (still reproducible on next-20200526) GOOD: next-20200515 git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git kernel config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkf… kernel crash log, ----------------------- [ 33.074161] ------------[ cut here ]------------ [ 33.079845] kernel BUG at /usr/src/kernel/arch/x86/kvm/mmu/mmu.c:3722! [ 33.086422] invalid opcode: 0000 [#1] SMP PTI [ 33.090792] CPU: 3 PID: 512 Comm: set_memory_regi Not tainted 5.7.0-rc7-next-20200526 #1 [ 33.100253] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.2 05/23/2018 [ 33.107642] RIP: 0010:kvm_mmu_load+0x407/0x420 [ 33.112086] Code: ff e9 42 fc ff ff 48 8b 0d f6 ec 99 01 e9 31 ff ff ff 48 8b 0d ea ec 99 01 e9 ac fe ff ff 48 8b 0d de ec 99 01 e9 af fd ff ff <0f> 0b 48 8b 0d d0 ec 99 01 eb 90 0f 1f 40 00 66 2e 0f 1f 84 00 00 [ 33.130829] RSP: 0018:ffffb225803d7d20 EFLAGS: 00010293 [ 33.136047] RAX: ffff936ee4fd8420 RBX: ffff936ee4fd8000 RCX: 0000000000000000 [ 33.143171] RDX: 0000000000000027 RSI: ffffffffacc81b20 RDI: ffff936ee76fb9a8 [ 33.150294] RBP: ffffb225803d7d50 R08: ffff936eefbb66c0 R09: ffff936eec668800 [ 33.157418] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 [ 33.164567] R13: 00000000002dc6c0 R14: ffff936ee4fd8000 R15: 0000000000000001 [ 33.171710] FS: 00007fce5aed3740(0000) GS:ffff936eefb80000(0000) knlGS:0000000000000000 [ 33.179787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.185525] CR2: 0000000000fdd298 CR3: 0000000263c74004 CR4: 00000000003626e0 [ 33.192682] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 33.199806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 33.206930] Call Trace: [ 33.209377] vcpu_enter_guest+0x10d0/0x17f0 [ 33.213580] ? kvm_load_guest_fpu.isra.131+0x4d/0x140 [ 33.218632] kvm_arch_vcpu_ioctl_run+0x12a/0x650 [ 33.223250] ? kvm_arch_vcpu_ioctl_run+0x12a/0x650 [ 33.228036] kvm_vcpu_ioctl+0x261/0x680 [ 33.231872] ? __audit_syscall_entry+0xdd/0x130 [ 33.236400] ksys_ioctl+0x98/0xb0 [ 33.239715] ? do_syscall_64+0x20/0xa0 [ 33.243461] __x64_sys_ioctl+0x1a/0x20 [ 33.247212] do_syscall_64+0x5a/0xa0 [ 33.250785] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 33.255836] RIP: 0033:0x7fce5a7d18f7 [ 33.259415] Code: b3 66 90 48 8b 05 a1 35 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 71 35 2c 00 f7 d8 64 89 01 48 [ 33.278152] RSP: 002b:00007ffca3313c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 33.285708] RAX: ffffffffffffffda RBX: 0000000000fdd3e0 RCX: 00007fce5a7d18f7 [ 33.292831] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 [ 33.299954] RBP: 0000000000000000 R08: 0000000000409dc3 R09: 0000000000000000 [ 33.307078] R10: 0000000000000001 R11: 0000000000000246 R12: 00000000004018a0 [ 33.314204] R13: 00007ffca3313e80 R14: 00007fce5aed36c0 R15: 0000000000000000 [ 33.321331] Modules linked in: x86_pkg_temp_thermal fuse [ 33.326672] ---[ end trace 76d29d87896dd85b ]--- [ 33.331308] RIP: 0010:kvm_mmu_load+0x407/0x420 [ 33.335753] Code: ff e9 42 fc ff ff 48 8b 0d f6 ec 99 01 e9 31 ff ff ff 48 8b 0d ea ec 99 01 e9 ac fe ff ff 48 8b 0d de ec 99 01 e9 af fd ff ff <0f> 0b 48 8b 0d d0 ec 99 01 eb 90 0f 1f 40 00 66 2e 0f 1f 84 00 00 [ 33.354497] RSP: 0018:ffffb225803d7d20 EFLAGS: 00010293 [ 33.359749] RAX: ffff936ee4fd8420 RBX: ffff936ee4fd8000 RCX: 0000000000000000 [ 33.366882] RDX: 0000000000000027 RSI: ffffffffacc81b20 RDI: ffff936ee76fb9a8 [ 33.374015] RBP: ffffb225803d7d50 R08: ffff936eefbb66c0 R09: ffff936eec668800 [ 33.381145] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 [ 33.388278] R13: 00000000002dc6c0 R14: ffff936ee4fd8000 R15: 0000000000000001 [ 33.395412] FS: 00007fce5aed3740(0000) GS:ffff936eefb80000(0000) knlGS:0000000000000000 [ 33.403496] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.409242] CR2: 0000000000fdd298 CR3: 0000000263c74004 CR4: 00000000003626e0 [ 33.416374] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 33.423509] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 t_memory_region_[ 33.431191] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#2] SMP PTI [ 33.442078] CPU: 1 PID: 512 Comm: set_memory_regi Tainted: G D 5.7.0-rc7-next-20200526 #1 [ 33.451541] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.2 05/23/2018 [ 33.458927] RIP: 0010:__schedule+0x48b/0x830 [ 33.463197] Code: 84 be fd ff ff 48 01 83 68 0c 00 00 48 83 83 60 0c 00 00 01 e9 aa fd ff ff 4d 8b bc 24 50 03 00 00 4d 85 ff 0f 84 c3 fd ff ff <49> 8b 47 10 4c 89 ff 4c 89 f6 48 8b 40 08 e8 f2 83 21 00 4d 8b 3f [ 33.481933] RSP: 0018:ffffb225803d7bf8 EFLAGS: 00010086 [ 33.487151] RAX: 0000000000000000 RBX: ffff936eefaacc00 RCX: 0000000000000002 [ 33.494276] RDX: 0000006500000000 RSI: 0000000000000000 RDI: ffff936ee4fd8000 [ 33.501398] RBP: ffffb225803d7c50 R08: 0000000000000000 R09: 0000000000000001 [ 33.508523] R10: ffffb225803d7b80 R11: 0000000000000197 R12: ffff936ee76fb100 [ 33.515646] R13: ffff936eefaacc18 R14: ffff936eee1d1880 R15: dead000000000100 [ 33.522771] FS: 00007fce5aed3740(0000) GS:ffff936eefa80000(0000) knlGS:0000000000000000 [ 33.530848] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.536586] CR2: 000055c5745b6280 CR3: 0000000207c10006 CR4: 00000000003626e0 [ 33.543710] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 33.550832] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 33.557957] Call Trace: [ 33.560406] preempt_schedule_common+0x15/0x30 [ 33.564849] _cond_resched+0x22/0x30 [ 33.568426] wait_for_completion+0x42/0x120 [ 33.572605] __synchronize_srcu+0xef/0x180 [ 33.576704] ? __bpf_trace_rcu_invoke_callback+0x10/0x10 [ 33.582017] synchronize_srcu+0x66/0x110 [ 33.585941] ? synchronize_srcu+0x66/0x110 [ 33.590031] kvm_page_track_unregister_notifier+0x4f/0x60 [ 33.595423] kvm_mmu_uninit_vm+0x15/0x20 [ 33.599340] kvm_arch_destroy_vm+0x1ab/0x210 [ 33.603604] kvm_put_kvm+0x1c6/0x3d0 [ 33.607176] kvm_vm_release+0x21/0x30 [ 33.610840] __fput+0x109/0x270 [ 33.613979] ____fput+0xe/0x10 [ 33.617037] task_work_run+0x6f/0xc0 [ 33.620609] do_exit+0x3ec/0xd10 [ 33.623842] rewind_stack_do_exit+0x17/0x17 [ 33.628024] RIP: 0033:0x7fce5a7d18f7 [ 33.631597] Code: Bad RIP value. [ 33.634821] RSP: 002b:00007ffca3313c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 33.642387] RAX: ffffffffffffffda RBX: 0000000000fdd3e0 RCX: 00007fce5a7d18f7 [ 33.649511] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 [ 33.656634] RBP: 0000000000000000 R08: 0000000000409dc3 R09: 0000000000000000 [ 33.663757] R10: 0000000000000001 R11: 0000000000000246 R12: 00000000004018a0 [ 33.670882] R13: 00007ffca3313e80 R14: 00007fce5aed36c0 R15: 0000000000000000 [ 33.678007] Modules linked in: x86_pkg_temp_thermal fuse [ 33.683320] ---[ end trace 76d29d87896dd85c ]--- [ 33.687937] RIP: 0010:kvm_mmu_load+0x407/0x420 [ 33.692373] Code: ff e9 42 fc ff ff 48 8b 0d f6 ec 99 01 e9 31 ff ff ff 48 8b 0d ea ec 99 01 e9 ac fe ff ff 48 8b 0d de ec 99 01 e9 af fd ff ff <0f> 0b 48 8b 0d d0 ec 99 01 eb 90 0f 1f 40 00 66 2e 0f 1f 84 00 00 [ 33.711111] RSP: 0018:ffffb225803d7d20 EFLAGS: 00010293 [ 33.716329] RAX: ffff936ee4fd8420 RBX: ffff936ee4fd8000 RCX: 0000000000000000 [ 33.723452] RDX: 0000000000000027 RSI: ffffffffacc81b20 RDI: ffff936ee76fb9a8 [ 33.730576] RBP: ffffb225803d7d50 R08: ffff936eefbb66c0 R09: ffff936eec668800 [ 33.737699] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 [ 33.744823] R13: 00000000002dc6c0 R14: ffff936ee4fd8000 R15: 0000000000000001 [ 33.751948] FS: 00007fce5aed3740(0000) GS:ffff936eefa80000(0000) knlGS:0000000000000000 [ 33.760024] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.765760] CR2: 00007fce5a7d18cd CR3: 0000000207c10006 CR4: 00000000003626e0 [ 33.772885] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 33.780009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 33.787132] note: set_memory_regi[512] exited with preempt_count 2 [ 33.793304] Fixing recursive fault but reboot is needed! Test job link, https://lkft.validation.linaro.org/scheduler/job/1455528#L1230 -- Linaro LKFT https://lkft.linaro.org

5 years, 1 month

2
2
0 0

[PATCH v3 kunit-next 0/2] kunit: extend kunit resources API

by Alan Maguire

A recent RFC patch set [1] suggests some additional functionality may be needed around kunit resources. It seems to require 1. support for resources without allocation 2. support for lookup of such resources 3. support for access to resources across multiple kernel threads The proposed changes here are designed to address these needs. The idea is we first generalize the API to support adding resources with static data; then from there we support named resources. The latter support is needed because if we are in a different thread context and only have the "struct kunit *" to work with, we need a way to identify a resource in lookup. [1] https://lkml.org/lkml/2020/2/26/1286 Changes since v2: - moved a few functions relating to resource retrieval in patches 1 and 2 into include/kunit/test.h and defined as "static inline"; this allows built-in consumers to use these functions when KUnit is built as a module Changes since v1: - reformatted longer parameter lists to have one parameter per-line (Brendan, patch 1) - fixed phrasing in various comments to clarify allocation of memory and added comment to kunit resource tests to clarify why kunit_put_resource() is used there (Brendan, patch 1) - changed #define to static inline function (Brendan, patch 2) - simplified kunit_add_named_resource() to use more of existing code for non-named resource (Brendan, patch 2) Alan Maguire (2): kunit: generalize kunit_resource API beyond allocated resources kunit: add support for named resources include/kunit/test.h | 211 +++++++++++++++++++++++++++++++++++++++------- lib/kunit/kunit-test.c | 111 +++++++++++++++++++----- lib/kunit/string-stream.c | 14 ++- lib/kunit/test.c | 172 ++++++++++++++++++++++--------------- 4 files changed, 382 insertions(+), 126 deletions(-) -- 1.8.3.1

5 years, 1 month

2
4
0 0

[PATCH v3 1/6] kunit: Kconfig: enable a KUNIT_ALL_TESTS fragment

by Anders Roxell

Make it easier to enable all KUnit fragments. This is useful for kernel devs or testers, so its easy to get all KUnit tests enabled and if new gets added they will be enabled as well. Fragments that has to be builtin will be missed if CONFIG_KUNIT_ALL_TESTS is set as a module. Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org> --- lib/kunit/Kconfig | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig index 95d12e3d6d95..bdeee7639005 100644 --- a/lib/kunit/Kconfig +++ b/lib/kunit/Kconfig @@ -41,4 +41,18 @@ config KUNIT_EXAMPLE_TEST is intended for curious hackers who would like to understand how to use KUnit for kernel development. +config KUNIT_ALL_TESTS + tristate "All KUnit tests with satisfied dependencies" + help + Enables all KUnit tests, if they can be enabled. + KUnit tests run during boot and output the results to the debug log + in TAP format (http://testanything.org/). Only useful for kernel devs + running the KUnit test harness, and not intended for inclusion into a + production build. + + 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. + endif # KUNIT -- 2.20.1

5 years, 1 month

2
1
0 0

[PATCH] selftests/ftrace: Return unsupported if no error_log file

by Masami Hiramatsu

Check whether error_log file exists in tracing/error_log testcase and return UNSUPPORTED if no error_log file. This can happen if we run the ftracetest on the older stable kernel. Fixes: 4eab1cc461a6 ("selftests/ftrace: Add tracing/error_log testcase") Cc: stable(a)vger.kernel.org Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> --- .../ftrace/test.d/ftrace/tracing-error-log.tc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/tracing-error-log.tc b/tools/testing/selftests/ftrace/test.d/ftrace/tracing-error-log.tc index 021c03fd885d..23465823532b 100644 --- a/tools/testing/selftests/ftrace/test.d/ftrace/tracing-error-log.tc +++ b/tools/testing/selftests/ftrace/test.d/ftrace/tracing-error-log.tc @@ -14,6 +14,8 @@ if [ ! -f set_event ]; then exit_unsupported fi +[ -f error_log ] || exit_unsupported + ftrace_errlog_check 'event filter parse error' '((sig >= 10 && sig < 15) || dsig ^== 17) && comm != bash' 'events/signal/signal_generate/filter' exit 0

5 years, 1 month

2
1
0 0

[PATCH 0/3] selftests/ftrace: Fix ftracetest testcases for dash, etc.

by Masami Hiramatsu

Hi, Here are some patches to update ftracetest to fix some issues. - [1/3] Fix coloring of XFAIL - [2/3] Fix a testcase not to expect just one event entry - [3/3] Do not use built-in echo because the behavior is different on dash and bash. (Thanks Liu for reporting!) Thank you, --- Masami Hiramatsu (3): selftests/ftrace: Make XFAIL green color selftests/ftrace: Pick only the first kprobe event to test selftests/ftrace: Use /bin/echo instead of built-in echo tools/testing/selftests/ftrace/ftracetest | 2 +- tools/testing/selftests/ftrace/test.d/functions | 3 +++ .../ftrace/test.d/kprobe/kprobe_args_type.tc | 2 +- .../test.d/trigger/trigger-trace-marker-hist.tc | 2 +- .../trigger-trace-marker-synthetic-kernel.tc | 4 ++++ .../trigger/trigger-trace-marker-synthetic.tc | 4 ++-- 6 files changed, 12 insertions(+), 5 deletions(-) -- Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>

5 years, 1 month

8
37
0 0

[PATCH bpf 0/5] bpf: fix map permissions check and cleanup code around

by Anton Protopopov

This series fixes a bug in the map_lookup_and_delete_elem() function which should check for the FMODE_CAN_READ bit, because it returns data to user space. The rest of commits fix some typos and comment in selftests and extend the test_map_wronly test to cover the new check for the BPF_MAP_TYPE_STACK and BPF_MAP_TYPE_QUEUE map types. Anton Protopopov (5): selftests/bpf: fix a typo in test_maps selftests/bpf: cleanup some file descriptors in test_maps selftests/bpf: cleanup comments in test_maps bpf: fix map permissions check selftests/bpf: add tests for write-only stacks/queues kernel/bpf/syscall.c | 3 +- tools/testing/selftests/bpf/test_maps.c | 52 ++++++++++++++++++++++--- 2 files changed, 49 insertions(+), 6 deletions(-) -- 2.20.1

5 years, 1 month

2
6
0 0

kselftest OOT run_tests

by Yauheni Kaliuta

Hi! I'm wondering how out of tree check is supposed to work for make O=dir run_tests from selftests (or make -C ...) directory? (both with 051f278e9d81 ("kbuild: replace KBUILD_SRCTREE with boolean building_out_of_srctree") and without) make M= ... does not work with run_tests. -- WBR, Yauheni Kaliuta

5 years, 1 month

3
7
0 0

selftests: cgroup: config fragments required

by Naresh Kamboju

selftest cgroup tests are getting skipped due to missing kernel config fragments. Please create the required config fragments "config" file. Our CI system merges these kernel config fragments and builds the kernel for testing. You may refer config files in other test directories. Test output log, # selftests cgroup test_memcontrol cgroup: test_memcontrol_ # [SKIP] not ok 1 # SKIP memory controller isn't available ok: 1_# [SKIP] [SKIP] 1 selftests cgroup test_memcontrol # SKIP selftests: cgroup_test_memcontrol [SKIP] # selftests cgroup test_core cgroup: test_core_ # [SKIP] not ok 1 # SKIP Failed to set memory controller ok: 1_# [SKIP] [SKIP] 2 selftests cgroup test_core # SKIP selftests: cgroup_test_core [SKIP] # selftests cgroup test_freezer cgroup: test_freezer_ # # ok 1 test_cgfreezer_simple 1: test_cgfreezer_simple_ # # ok 2 test_cgfreezer_tree 2: test_cgfreezer_tree_ # # ok 3 test_cgfreezer_forkbomb 3: test_cgfreezer_forkbomb_ # # ok 4 test_cgfreezer_mkdir 4: test_cgfreezer_mkdir_ # # ok 5 test_cgfreezer_rmdir 5: test_cgfreezer_rmdir_ # # ok 6 test_cgfreezer_migrate 6: test_cgfreezer_migrate_ # # Cgroup /sys/fs/cgroup/unified/cg_test_ptrace isn't frozen /sys/fs/cgroup/unified/cg_test_ptrace: isn't_frozen # # not ok 7 test_cgfreezer_ptrace ok: 7_test_cgfreezer_ptrace # # ok 8 test_cgfreezer_stopped 8: test_cgfreezer_stopped_ # # ok 9 test_cgfreezer_ptraced 9: test_cgfreezer_ptraced_ # # ok 10 test_cgfreezer_vfork 10: test_cgfreezer_vfork_ # [FAIL] 3 selftests cgroup test_freezer # exit=1 selftests: cgroup_test_freezer [FAIL] # selftests cgroup test_stress.sh cgroup: test_stress.sh_ # # ./with_stress.sh line 34 echo write error No such file or directory line: 34_echo # # Skipping cannot enable cpuset in /sys/fs/cgroup/unified cannot: enable_cpuset # [SKIP] 4 selftests cgroup test_stress.sh # SKIP selftests: cgroup_test_stress.sh [SKIP] You may create config file like this, CONFIG_CGROUPS=y CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_HUGETLB=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y -- Linaro LKFT https://lkft.linaro.org

5 years, 1 month

1
0
0 0

Re: [PATCH v3 3/7] kunit: tests for stats_fs API

by Alan Maguire

On Tue, 26 May 2020, Emanuele Giuseppe Esposito wrote: > Add kunit tests to extensively test the stats_fs API functionality. > I've added in the kunit-related folks. > In order to run them, the kernel .config must set CONFIG_KUNIT=y > and a new .kunitconfig file must be created with CONFIG_STATS_FS=y > and CONFIG_STATS_FS_TEST=y > It looks like CONFIG_STATS_FS is built-in, but it exports much of the functionality you are testing. However could the tests also be built as a module (i.e. make CONFIG_STATS_FS_TEST a tristate variable)? To test this you'd need to specify CONFIG_KUNIT=m and CONFIG_STATS_FS_TEST=m, and testing would simply be a case of "modprobe"ing the stats fs module and collecting results in /sys/kernel/debug/kunit/<module_name> (rather than running kunit.py). Are you relying on unexported internals in the the tests that would prevent building them as a module? Thanks! Alan

5 years, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror