August 2022 - Linux-kselftest-mirror

[PATCH] drm/mm: Reduce stack frame usage in __igt_reserve

by Maíra Canal

The struct drm_mm is being allocated on the stack, which is causing the following -Wframe-larger-than warning on ARM: ../drivers/gpu/drm/tests/drm_mm_test.c:344:12: error: stack frame size (1064) exceeds limit (1024) in '__igt_reserve' [-Werror,-Wframe-larger-than] static int __igt_reserve(struct kunit *test, unsigned int count, u64 size) ^ 1 error generated. So, fix this warning by dynamically allocating the struct drm_mm. Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Maíra Canal <mairacanal(a)riseup.net> --- drivers/gpu/drm/tests/drm_mm_test.c | 33 ++++++++++++++++------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/tests/drm_mm_test.c b/drivers/gpu/drm/tests/drm_mm_test.c index 1e2c1aa524bd..fbd8dcbc12ee 100644 --- a/drivers/gpu/drm/tests/drm_mm_test.c +++ b/drivers/gpu/drm/tests/drm_mm_test.c @@ -344,7 +344,7 @@ static bool check_reserve_boundaries(struct kunit *test, struct drm_mm *mm, static int __igt_reserve(struct kunit *test, unsigned int count, u64 size) { DRM_RND_STATE(prng, random_seed); - struct drm_mm mm; + struct drm_mm *mm; struct drm_mm_node tmp, *nodes, *node, *next; unsigned int *order, n, m, o = 0; int ret, err; @@ -366,17 +366,20 @@ static int __igt_reserve(struct kunit *test, unsigned int count, u64 size) nodes = vzalloc(array_size(count, sizeof(*nodes))); KUNIT_ASSERT_TRUE(test, nodes); + mm = kunit_kzalloc(test, sizeof(struct drm_mm), GFP_KERNEL); + KUNIT_ASSERT_NOT_NULL(test, mm); + ret = -EINVAL; - drm_mm_init(&mm, 0, count * size); + drm_mm_init(mm, 0, count * size); - if (!check_reserve_boundaries(test, &mm, count, size)) + if (!check_reserve_boundaries(test, mm, count, size)) goto out; for (n = 0; n < count; n++) { nodes[n].start = order[n] * size; nodes[n].size = size; - err = drm_mm_reserve_node(&mm, &nodes[n]); + err = drm_mm_reserve_node(mm, &nodes[n]); if (err) { KUNIT_FAIL(test, "reserve failed, step %d, start %llu\n", n, nodes[n].start); @@ -390,23 +393,23 @@ static int __igt_reserve(struct kunit *test, unsigned int count, u64 size) goto out; } - if (!expect_reserve_fail(test, &mm, &nodes[n])) + if (!expect_reserve_fail(test, mm, &nodes[n])) goto out; } /* After random insertion the nodes should be in order */ - if (!assert_continuous(test, &mm, size)) + if (!assert_continuous(test, mm, size)) goto out; /* Repeated use should then fail */ drm_random_reorder(order, count, &prng); for (n = 0; n < count; n++) { - if (!expect_reserve_fail(test, &mm, set_node(&tmp, order[n] * size, 1))) + if (!expect_reserve_fail(test, mm, set_node(&tmp, order[n] * size, 1))) goto out; /* Remove and reinsert should work */ drm_mm_remove_node(&nodes[order[n]]); - err = drm_mm_reserve_node(&mm, &nodes[order[n]]); + err = drm_mm_reserve_node(mm, &nodes[order[n]]); if (err) { KUNIT_FAIL(test, "reserve failed, step %d, start %llu\n", n, nodes[n].start); @@ -415,16 +418,16 @@ static int __igt_reserve(struct kunit *test, unsigned int count, u64 size) } } - if (!assert_continuous(test, &mm, size)) + if (!assert_continuous(test, mm, size)) goto out; /* Overlapping use should then fail */ for (n = 0; n < count; n++) { - if (!expect_reserve_fail(test, &mm, set_node(&tmp, 0, size * count))) + if (!expect_reserve_fail(test, mm, set_node(&tmp, 0, size * count))) goto out; } for (n = 0; n < count; n++) { - if (!expect_reserve_fail(test, &mm, set_node(&tmp, size * n, size * (count - n)))) + if (!expect_reserve_fail(test, mm, set_node(&tmp, size * n, size * (count - n)))) goto out; } @@ -437,7 +440,7 @@ static int __igt_reserve(struct kunit *test, unsigned int count, u64 size) for (m = 0; m < n; m++) { node = &nodes[order[(o + m) % count]]; - err = drm_mm_reserve_node(&mm, node); + err = drm_mm_reserve_node(mm, node); if (err) { KUNIT_FAIL(test, "reserve failed, step %d/%d, start %llu\n", m, n, node->start); @@ -448,15 +451,15 @@ static int __igt_reserve(struct kunit *test, unsigned int count, u64 size) o += n; - if (!assert_continuous(test, &mm, size)) + if (!assert_continuous(test, mm, size)) goto out; } ret = 0; out: - drm_mm_for_each_node_safe(node, next, &mm) + drm_mm_for_each_node_safe(node, next, mm) drm_mm_remove_node(node); - drm_mm_takedown(&mm); + drm_mm_takedown(mm); vfree(nodes); kfree(order); err: -- 2.37.2

2 years, 4 months

1
0
0 0

[PATCH] kvm/rseq_test.c:Correct gettid func name kselftest

by Akhil Raj

I got the following error message when I ran make kselftest summary=1 TARGETS=kvm rseq_test.c: In function ‘main’: rseq_test.c:230:33: warning: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Wimplicit-function-declaration] (void *)(unsigned long)gettid()); ^~~~~~ getgid /tmp/ccNexT4G.o: In function `main': linux_mainline/tools/testing/selftests/kvm/rseq_test.c:230: undefined reference to `gettid' collect2: error: ld returned 1 exit status ../lib.mk:136: recipe for target 'linux_mainline/tools/testing/selftests/kvm/rseq_test' failed As per suggestion I renamed gettid to getgid after rerunning the kselftest command the following selftests messages were returned not ok 7 selftests: kvm: hyperv_clock # exit=254 not ok 11 selftests: kvm: kvm_clock_test # exit=254 not ok 51 selftests: kvm: access_tracking_perf_test # exit=254 not ok 53 selftests: kvm: dirty_log_test # exit=254 not ok 58 selftests: kvm: max_guest_memory_test # TIMEOUT 120 seconds not ok 60 selftests: kvm: memslot_perf_test # exit=142 Signed-off-by: Akhil Raj <lf32.dev(a)gmail.com> --- tools/testing/selftests/kvm/rseq_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c index fac248a43666..aa83a0537f0c 100644 --- a/tools/testing/selftests/kvm/rseq_test.c +++ b/tools/testing/selftests/kvm/rseq_test.c @@ -227,7 +227,7 @@ int main(int argc, char *argv[]) ucall_init(vm, NULL); pthread_create(&migration_thread, NULL, migration_worker, - (void *)(unsigned long)gettid()); + (void *)(unsigned long)getgid()); for (i = 0; !done; i++) { vcpu_run(vcpu); -- 2.17.1

2 years, 4 months

1
0
0 0

[PATCH v13 00/10] bpf: Add kfuncs for PKCS#7 signature verification

by Roberto Sassu

From: Roberto Sassu <roberto.sassu(a)huawei.com> One of the desirable features in security is the ability to restrict import of data to a given system based on data authenticity. If data import can be restricted, it would be possible to enforce a system-wide policy based on the signing keys the system owner trusts. This feature is widely used in the kernel. For example, if the restriction is enabled, kernel modules can be plugged in only if they are signed with a key whose public part is in the primary or secondary keyring. For eBPF, it can be useful as well. For example, it might be useful to authenticate data an eBPF program makes security decisions on. After a discussion in the eBPF mailing list, it was decided that the stated goal should be accomplished by introducing four new kfuncs: bpf_lookup_user_key() and bpf_lookup_system_key(), for retrieving a keyring with keys trusted for signature verification, respectively from its serial and from a pre-determined ID; bpf_key_put(), to release the reference obtained with the former two kfuncs, bpf_verify_pkcs7_signature(), for verifying PKCS#7 signatures. Other than the key serial, bpf_lookup_user_key() also accepts key lookup flags, that influence the behavior of the lookup. bpf_lookup_system_key() accepts pre-determined IDs defined in include/linux/verification.h. bpf_key_put() accepts the new bpf_key structure, introduced to tell whether the other structure member, a key pointer, is valid or not. The reason is that verify_pkcs7_signature() also accepts invalid pointers, set with the pre-determined ID, to select a system-defined keyring. key_put() must be called only for valid key pointers. Since the two key lookup functions allocate memory and one increments a key reference count, they must be used in conjunction with bpf_key_put(). The latter must be called only if the lookup functions returned a non-NULL pointer. The verifier denies the execution of eBPF programs that don't respect this rule. The two key lookup functions should be used in alternative, depending on the use case. While bpf_lookup_user_key() provides great flexibility, it seems suboptimal in terms of security guarantees, as even if the eBPF program is assumed to be trusted, the serial used to obtain the key pointer might come from untrusted user space not choosing one that the system administrator approves to enforce a mandatory policy. bpf_lookup_system_key() instead provides much stronger guarantees, especially if the pre-determined ID is not passed by user space but is hardcoded in the eBPF program, and that program is signed. In this case, bpf_verify_pkcs7_signature() will always perform signature verification with a key that the system administrator approves, i.e. the primary, secondary or platform keyring. Nevertheless, key permission checks need to be done accurately. Since bpf_lookup_user_key() cannot determine how a key will be used by other kfuncs, it has to defer the permission check to the actual kfunc using the key. It does it by calling lookup_user_key() with KEY_DEFER_PERM_CHECK as needed permission. Later, bpf_verify_pkcs7_signature(), if called, completes the permission check by calling key_validate(). It does not need to call key_task_permission() with permission KEY_NEED_SEARCH, as it is already done elsewhere by the key subsystem. Future kfuncs using the bpf_key structure need to implement the proper checks as well. Finally, the last kfunc, bpf_verify_pkcs7_signature(), accepts the data and signature to verify as eBPF dynamic pointers, to minimize the number of kfunc parameters, and the keyring with keys for signature verification as a bpf_key structure, returned by one of the two key lookup functions. bpf_lookup_user_key() and bpf_verify_pkcs7_signature() can be called only from sleepable programs, because of memory allocation and crypto operations. For example, the lsm.s/bpf attach point is suitable, fexit/array_map_update_elem is not. The correctness of implementation of the new kfuncs and of their usage is checked with the introduced tests. The patch set includes a patch from another author (dependency) for sake of completeness. It is organized as follows. Patch 1 from KP Singh allows kfuncs to be used by LSM programs. Patch 2 allows dynamic pointers to be used as kfunc parameters. Patch 3 exports bpf_dynptr_get_size(), to obtain the real size of data carried by a dynamic pointer. Patch 4 makes available for new eBPF kfuncs some key-related definitions. Patch 5 introduces the bpf_lookup_*_key() and bpf_key_put() kfuncs. Patch 6 introduces the bpf_verify_pkcs7_signature() kfunc. Patch 7 changes the testing kernel configuration to compile everything as built-in. Finally, patches 8-10 introduce the tests. Changelog v12: - Blacklist lookup_key and verify_pkcs7_sig tests for s390x (JIT does not support calling kernel function) v11: - Move stringify_struct() macro to include/linux/btf.h (suggested by Daniel) - Change kernel configuration options in tools/testing/selftests/bpf/config* from =m to =y v10: - Introduce key_lookup_flags_check() and system_keyring_id_check() inline functions to check parameters (suggested by KP) - Fix descriptions and comment of key-related kfuncs (suggested by KP) - Register kfunc set only once (suggested by Alexei) - Move needed kernel options to the architecture-independent configuration for testing v9: - Drop patch to introduce KF_SLEEPABLE kfunc flag (already merged) - Rename valid_ptr member of bpf_key to has_ref (suggested by Daniel) - Check dynamic pointers in kfunc definition with bpf_dynptr_kern struct definition instead of string, to detect structure renames (suggested by Daniel) - Explicitly say that we permit initialized dynamic pointers in kfunc definition (suggested by Daniel) - Remove noinline __weak from kfuncs definition (reported by Daniel) - Simplify key lookup flags check in bpf_lookup_user_key() (suggested by Daniel) - Explain the reason for deferring key permission check (suggested by Daniel) - Allocate memory with GFP_ATOMIC in bpf_lookup_system_key(), and remove KF_SLEEPABLE kfunc flag from kfunc declaration (suggested by Daniel) - Define only one kfunc set and remove the loop for registration (suggested by Alexei) v8: - Define the new bpf_key structure to carry the key pointer and whether that pointer is valid or not (suggested by Daniel) - Drop patch to mark a kfunc parameter with the __maybe_null suffix - Improve documentation of kfuncs - Introduce bpf_lookup_system_key() to obtain a key pointer suitable for verify_pkcs7_signature() (suggested by Daniel) - Use the new kfunc registration API - Drop patch to test the __maybe_null suffix - Add tests for bpf_lookup_system_key() v7: - Add support for using dynamic and NULL pointers in kfunc (suggested by Alexei) - Add new kfunc-related tests v6: - Switch back to key lookup helpers + signature verification (until v5), and defer permission check from bpf_lookup_user_key() to bpf_verify_pkcs7_signature() - Add additional key lookup test to illustrate the usage of the KEY_LOOKUP_CREATE flag and validate the flags (suggested by Daniel) - Make description of flags of bpf_lookup_user_key() more user-friendly (suggested by Daniel) - Fix validation of flags parameter in bpf_lookup_user_key() (reported by Daniel) - Rename bpf_verify_pkcs7_signature() keyring-related parameters to user_keyring and system_keyring to make their purpose more clear - Accept keyring-related parameters of bpf_verify_pkcs7_signature() as alternatives (suggested by KP) - Replace unsigned long type with u64 in helper declaration (suggested by Daniel) - Extend the bpf_verify_pkcs7_signature() test by calling the helper without data, by ensuring that the helper enforces the keyring-related parameters as alternatives, by ensuring that the helper rejects inaccessible and expired keyrings, and by checking all system keyrings - Move bpf_lookup_user_key() and bpf_key_put() usage tests to ref_tracking.c (suggested by John) - Call bpf_lookup_user_key() and bpf_key_put() only in sleepable programs v5: - Move KEY_LOOKUP_ to include/linux/key.h for validation of bpf_verify_pkcs7_signature() parameter - Remove bpf_lookup_user_key() and bpf_key_put() helpers, and the corresponding tests - Replace struct key parameter of bpf_verify_pkcs7_signature() with the keyring serial and lookup flags - Call lookup_user_key() and key_put() in bpf_verify_pkcs7_signature() code, to ensure that the retrieved key is used according to the permission requested at lookup time - Clarified keyring precedence in the description of bpf_verify_pkcs7_signature() (suggested by John) - Remove newline in the second argument of ASSERT_ - Fix helper prototype regular expression in bpf_doc.py v4: - Remove bpf_request_key_by_id(), don't return an invalid pointer that other helpers can use - Pass the keyring ID (without ULONG_MAX, suggested by Alexei) to bpf_verify_pkcs7_signature() - Introduce bpf_lookup_user_key() and bpf_key_put() helpers (suggested by Alexei) - Add lookup_key_norelease test, to ensure that the verifier blocks eBPF programs which don't decrement the key reference count - Parse raw PKCS#7 signature instead of module-style signature in the verify_pkcs7_signature test (suggested by Alexei) - Parse kernel module in user space and pass raw PKCS#7 signature to the eBPF program for signature verification v3: - Rename bpf_verify_signature() back to bpf_verify_pkcs7_signature() to avoid managing different parameters for each signature verification function in one helper (suggested by Daniel) - Use dynamic pointers and export bpf_dynptr_get_size() (suggested by Alexei) - Introduce bpf_request_key_by_id() to give more flexibility to the caller of bpf_verify_pkcs7_signature() to retrieve the appropriate keyring (suggested by Alexei) - Fix test by reordering the gcc command line, always compile sign-file - Improve helper support check mechanism in the test v2: - Rename bpf_verify_pkcs7_signature() to a more generic bpf_verify_signature() and pass the signature type (suggested by KP) - Move the helper and prototype declaration under #ifdef so that user space can probe for support for the helper (suggested by Daniel) - Describe better the keyring types (suggested by Daniel) - Include linux/bpf.h instead of vmlinux.h to avoid implicit or redeclaration - Make the test selfcontained (suggested by Alexei) v1: - Don't define new map flag but introduce simple wrapper of verify_pkcs7_signature() (suggested by Alexei and KP) KP Singh (1): bpf: Allow kfuncs to be used in LSM programs Roberto Sassu (9): btf: Handle dynamic pointer parameter in kfuncs bpf: Export bpf_dynptr_get_size() KEYS: Move KEY_LOOKUP_ to include/linux/key.h bpf: Add bpf_lookup_*_key() and bpf_key_put() kfuncs bpf: Add bpf_verify_pkcs7_signature() kfunc selftests/bpf: Compile kernel with everything as built-in selftests/bpf: Add verifier tests for bpf_lookup_*_key() and bpf_key_put() selftests/bpf: Add additional tests for bpf_lookup_*_key() selftests/bpf: Add test for bpf_verify_pkcs7_signature() kfunc include/linux/bpf.h | 7 + include/linux/bpf_verifier.h | 3 + include/linux/btf.h | 9 + include/linux/key.h | 11 + include/linux/verification.h | 8 + kernel/bpf/btf.c | 19 + kernel/bpf/helpers.c | 2 +- kernel/bpf/verifier.c | 4 +- kernel/trace/bpf_trace.c | 180 ++++++++ security/keys/internal.h | 2 - tools/testing/selftests/bpf/DENYLIST.s390x | 2 + tools/testing/selftests/bpf/Makefile | 14 +- tools/testing/selftests/bpf/config | 32 +- tools/testing/selftests/bpf/config.x86_64 | 7 +- .../selftests/bpf/prog_tests/lookup_key.c | 112 +++++ .../bpf/prog_tests/verify_pkcs7_sig.c | 399 ++++++++++++++++++ .../selftests/bpf/progs/test_lookup_key.c | 46 ++ .../bpf/progs/test_verify_pkcs7_sig.c | 100 +++++ tools/testing/selftests/bpf/test_verifier.c | 3 +- .../selftests/bpf/verifier/ref_tracking.c | 139 ++++++ .../testing/selftests/bpf/verify_sig_setup.sh | 104 +++++ 21 files changed, 1175 insertions(+), 28 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/lookup_key.c create mode 100644 tools/testing/selftests/bpf/prog_tests/verify_pkcs7_sig.c create mode 100644 tools/testing/selftests/bpf/progs/test_lookup_key.c create mode 100644 tools/testing/selftests/bpf/progs/test_verify_pkcs7_sig.c create mode 100755 tools/testing/selftests/bpf/verify_sig_setup.sh -- 2.25.1

2 years, 4 months

4
17
0 0

[PATCH -next 0/5] landlock: add chmod and chown support

by Xiu Jianfeng

hi, this patchset adds chmod and chown support for landlock Xiu Jianfeng (5): landlock: expand access_mask_t to u32 type landlock: add chmod and chown support landlock/selftests: add selftests for chmod and chown landlock/samples: add chmod and chown support landlock: update chmod and chown support in document Documentation/userspace-api/landlock.rst | 8 +- include/uapi/linux/landlock.h | 8 +- samples/landlock/sandboxer.c | 12 +- security/landlock/fs.c | 16 +- security/landlock/limits.h | 2 +- security/landlock/ruleset.h | 2 +- security/landlock/syscalls.c | 2 +- tools/testing/selftests/landlock/base_test.c | 2 +- tools/testing/selftests/landlock/fs_test.c | 234 ++++++++++++++++++- 9 files changed, 274 insertions(+), 12 deletions(-) -- 2.17.1

2 years, 4 months

5
26
0 0

[PATCH] selftests/bpf: declare subprog_noise as static in tailcall_bpf2bpf4

by James Hilliard

Due to bpf_map_lookup_elem being declared static we need to also declare subprog_noise as static. Fixes the following error: progs/tailcall_bpf2bpf4.c:26:9: error: 'bpf_map_lookup_elem' is static but used in inline function 'subprog_noise' which is not static [-Werror] 26 | bpf_map_lookup_elem(&nop_table, &key); | ^~~~~~~~~~~~~~~~~~~ Signed-off-by: James Hilliard <james.hilliard1(a)gmail.com> --- tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c index b67e8022d500..a017d6b2f1dd 100644 --- a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c +++ b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c @@ -19,7 +19,7 @@ struct { int count = 0; int noise = 0; -__always_inline int subprog_noise(void) +static __always_inline int subprog_noise(void) { __u32 key = 0; -- 2.34.1

2 years, 4 months

3
2
0 0

Re: linux-next: Tree for Aug 25 (kunit: virt/nitro_enclaves; also kexec)

by Randy Dunlap

On 8/24/22 22:44, Stephen Rothwell wrote: > Hi all, > > Changes since 20220824: > on x86_64: ld: vmlinux.o: in function `kunit_kcalloc': include/kunit/test.h:369: undefined reference to `kunit_kmalloc_array' ld: vmlinux.o: in function `ne_misc_dev_test_merge_phys_contig_memory_regions': drivers/virt/nitro_enclaves/ne_misc_dev_test.c:120: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:128: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:128: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:129: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:129: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:135: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:135: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:137: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:137: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:141: undefined reference to `kunit_kfree' ld: vmlinux.o: in function `kexec_purgatory_size': (.rodata+0x209ee0): undefined reference to `kunit_unary_assert_format' Full randconfig file is attached. -- ~Randy

2 years, 4 months

2
1
0 0

[PATCH] selftests/bpf: fix type conflict in test_tc_dtime

by James Hilliard

The sys/socket.h header isn't required to build test_tc_dtime and may cause a type conflict. Fixes the following error: In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155, from /usr/include/x86_64-linux-gnu/bits/socket.h:29, from /usr/include/x86_64-linux-gnu/sys/socket.h:33, from progs/test_tc_dtime.c:18: /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:24:18: error: conflicting types for 'int8_t'; have '__int8_t' {aka 'signed char'} 24 | typedef __int8_t int8_t; | ^~~~~~ In file included from progs/test_tc_dtime.c:5: /home/buildroot/opt/cross/lib/gcc/bpf/13.0.0/include/stdint.h:34:23: note: previous declaration of 'int8_t' with type 'int8_t' {aka 'char'} 34 | typedef __INT8_TYPE__ int8_t; | ^~~~~~ /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: error: conflicting types for 'int64_t'; have '__int64_t' {aka 'long long int'} 27 | typedef __int64_t int64_t; | ^~~~~~~ /home/buildroot/opt/cross/lib/gcc/bpf/13.0.0/include/stdint.h:43:24: note: previous declaration of 'int64_t' with type 'int64_t' {aka 'long int'} 43 | typedef __INT64_TYPE__ int64_t; | ^~~~~~~ make: *** [Makefile:537: /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/test_tc_dtime.o] Error 1 Signed-off-by: James Hilliard <james.hilliard1(a)gmail.com> --- tools/testing/selftests/bpf/progs/test_tc_dtime.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/bpf/progs/test_tc_dtime.c b/tools/testing/selftests/bpf/progs/test_tc_dtime.c index b596479a9ebe..125beec31834 100644 --- a/tools/testing/selftests/bpf/progs/test_tc_dtime.c +++ b/tools/testing/selftests/bpf/progs/test_tc_dtime.c @@ -15,7 +15,6 @@ #include <linux/udp.h> #include <bpf/bpf_helpers.h> #include <bpf/bpf_endian.h> -#include <sys/socket.h> /* veth_src --- veth_src_fwd --- veth_det_fwd --- veth_dst * | | -- 2.34.1

2 years, 4 months

3
2
0 0

[PATCH v2 0/8] Documentation: Kunit: clean kunit-tool.rst and start.rst

by Tales Aparecida

Hi, Continuing the documentation refactoring started by Harinder Singh[1], removes kunit-tool.rst, which had its information rearranged into run_wrapper, and employs further work in the index and the getting-started guide. This series was written on top of another[2] that haven't got applied yet, but the only dependency it has is the "kunit-on-qemu" anchor used in start.rst. Changelog: v1 -> v2: - Update expected output for `kunit.py run` from "Generating .config ..." to "Configuring KUnit Kernel ..." - Update run_wrapper titles as suggested by Sadiya Kazi - Remove confusing recommendation from start.rst intro, highlighted by Tim Bird - Fix grammars nits pointed by Maíra Canal and Sadiya Kazi - Add some reviewed-by Thanks again for your feedbacks, Tales [1] https://lore.kernel.org/r/20211217044911.798817-1-sharinder@google.com/ [2] https://lore.kernel.org/r/20220813042055.136832-1-tales.aparecida@gmail.com/ Tales Aparecida (8): Documentation: KUnit: remove duplicated docs for kunit_tool Documentation: KUnit: avoid repeating "kunit.py run" in start.rst Documentation: KUnit: add note about mrproper in start.rst Documentation: KUnit: Reword start guide for selecting tests Documentation: KUnit: add intro to the getting-started page Documentation: KUnit: update links in the index page lib: overflow: update reference to kunit-tool lib: stackinit: update reference to kunit-tool Documentation/dev-tools/kunit/index.rst | 16 +- Documentation/dev-tools/kunit/kunit-tool.rst | 232 ------------------ Documentation/dev-tools/kunit/run_wrapper.rst | 34 +-- Documentation/dev-tools/kunit/start.rst | 136 ++++++---- lib/overflow_kunit.c | 2 +- lib/stackinit_kunit.c | 2 +- 6 files changed, 117 insertions(+), 305 deletions(-) delete mode 100644 Documentation/dev-tools/kunit/kunit-tool.rst base-commit: 568035b01cfb107af8d2e4bd2fb9aea22cf5b868 prerequisite-patch-id: b794218cd939a6644aaf5fb2a73997c56a624c80 prerequisite-patch-id: ccd24491ae99152ebdc6dcb8ddb9499d3456a4a0 prerequisite-patch-id: cc17b80d42fd5f5049e144da5c04e922036a33eb prerequisite-patch-id: ba7edd270c6f285352e0e17bfe65ff6119192113 -- 2.37.2

2 years, 4 months

4
20
0 0

[PATCH 0/8] Documentation: Kunit: clean kunit-tool.rst and start.rst

by Tales Aparecida

Hi, Continuing the documentation refactoring started by Harinder Singh[1], removes kunit-tool.rst, which had its information rearranged into run_wrapper, and employs further work in the index and the getting-started guide. This series was written on top of another[2] that haven't got applied yet, but the only dependency it has is the "kunit-on-qemu" anchor used in start.rst. The patches working with the start.rst might be squashable, feel free to suggest so, if you concur. Still about this file, I realize the note about "mrproper" was removed in the recent refactoring, but having worked in the last months with people new to kunit, it showed itself as a common occurrence, so I'm suggesting here to restore it. Regarding the last two patches, I wasn't sure about either renaming run_wrapper to kunit-tool to keep old references working or do as I did, updating the references I could find. Thanks in advance for your feedbacks, Tales [1] https://lore.kernel.org/r/20211217044911.798817-1-sharinder@google.com/ [2] https://lore.kernel.org/r/20220813042055.136832-1-tales.aparecida@gmail.com/ Tales Aparecida (8): Documentation: KUnit: remove duplicated docs for kunit_tool Documentation: KUnit: avoid repeating "kunit.py run" in start.rst Documentation: KUnit: restore note about mrproper in start.rst Documentation: KUnit: Reword start guide for selecting tests Documentation: KUnit: add intro to the getting-started page Documentation: KUnit: update links in the index page lib: overflow: update reference to kunit-tool lib: stackinit: update reference to kunit-tool Documentation/dev-tools/kunit/index.rst | 16 +- Documentation/dev-tools/kunit/kunit-tool.rst | 232 ------------------ Documentation/dev-tools/kunit/run_wrapper.rst | 4 +- Documentation/dev-tools/kunit/start.rst | 137 +++++++---- lib/overflow_kunit.c | 2 +- lib/stackinit_kunit.c | 2 +- 6 files changed, 103 insertions(+), 290 deletions(-) delete mode 100644 Documentation/dev-tools/kunit/kunit-tool.rst base-commit: 568035b01cfb107af8d2e4bd2fb9aea22cf5b868 prerequisite-patch-id: b794218cd939a6644aaf5fb2a73997c56a624c80 prerequisite-patch-id: ccd24491ae99152ebdc6dcb8ddb9499d3456a4a0 prerequisite-patch-id: cc17b80d42fd5f5049e144da5c04e922036a33eb prerequisite-patch-id: ba7edd270c6f285352e0e17bfe65ff6119192113 -- 2.37.1

2 years, 4 months

8
22
0 0

[PATCH] Documentation: KUnit: Reword kunit_tool guide

by Sadiya Kazi

Updated the kunit_tool.rst guide to streamline it. The following changes were made: 1. Updated headings 2. Reworded content across sections 3. Added a cross reference to full list of command-line args Signed-off-by: Sadiya Kazi <sadiyakazi(a)google.com> --- Documentation/dev-tools/kunit/kunit-tool.rst | 82 ++++++++++---------- 1 file changed, 42 insertions(+), 40 deletions(-) diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index ae52e0f489f9..33186679f5de 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -1,8 +1,10 @@ .. SPDX-License-Identifier: GPL-2.0 -================= -kunit_tool How-To -================= +======================== +Understanding kunit_tool +======================== + +This page introduces the kunit_tool and covers the concepts and working of this tool. What is kunit_tool? =================== @@ -10,39 +12,37 @@ What is kunit_tool? kunit_tool is a script (``tools/testing/kunit/kunit.py``) that aids in building the Linux kernel as UML (`User Mode Linux <http://user-mode-linux.sourceforge.net/>`_), running KUnit tests, parsing -the test results and displaying them in a user friendly manner. +the test results and displaying them in a user-friendly manner. kunit_tool addresses the problem of being able to run tests without needing a virtual machine or actual hardware with User Mode Linux. User Mode Linux is a Linux architecture, like ARM or x86; however, unlike other architectures it -compiles the kernel as a standalone Linux executable that can be run like any +compiles the kernel as a standalone Linux executable. This executable can be run like any other program directly inside of a host operating system. To be clear, it does not require any virtualization support: it is just a regular program. -What is a .kunitconfig? -======================= +What is .kunitconfig? +===================== -It's just a defconfig that kunit_tool looks for in the build directory -(``.kunit`` by default). kunit_tool uses it to generate a .config as you might -expect. In addition, it verifies that the generated .config contains the CONFIG -options in the .kunitconfig; the reason it does this is so that it is easy to -be sure that a CONFIG that enables a test actually ends up in the .config. +.kunitconfig is a default configuration file (defconfig) that kunit_tool looks +for in the build directory (``.kunit``). The kunit_tool uses this file to +generate a .config. Additionally, it also verifies that the generated .config contains the CONFIG options in the .kunitconfig file. This is done to make sure that a CONFIG that enables a test is actually part of the .config file. -It's also possible to pass a separate .kunitconfig fragment to kunit_tool, +It is also possible to pass a separate .kunitconfig fragment to kunit_tool, which is useful if you have several different groups of tests you wish -to run independently, or if you want to use pre-defined test configs for +to run independently, or if you want to use pre-defined test configurations for certain subsystems. -Getting Started with kunit_tool +Getting started with kunit_tool =============================== -If a kunitconfig is present at the root directory, all you have to do is: +If a kunitconfig is present at the root directory, run the following command: .. code-block:: bash ./tools/testing/kunit/kunit.py run -However, you most likely want to use it with the following options: +However, most likely you may want to use it with the following options: .. code-block:: bash @@ -68,20 +68,20 @@ For a list of all the flags supported by kunit_tool, you can run: ./tools/testing/kunit/kunit.py run --help -Configuring, Building, and Running Tests +Configuring, building, and running tests ======================================== -It's also possible to run just parts of the KUnit build process independently, -which is useful if you want to make manual changes to part of the process. +It is also possible to run specific parts of the KUnit build process independently. +This is useful if you want to make manual changes to part of the process. -A .config can be generated from a .kunitconfig by using the ``config`` argument +If you want to generate a .config from a .kunitconfig, you can use the ``config`` argument when running kunit_tool: .. code-block:: bash ./tools/testing/kunit/kunit.py config -Similarly, if you just want to build a KUnit kernel from the current .config, +Similarly, if you want to build a KUnit kernel from the current .config, you can use the ``build`` argument: .. code-block:: bash @@ -95,33 +95,31 @@ run the kernel and display the test results with the ``exec`` argument: ./tools/testing/kunit/kunit.py exec -The ``run`` command which is discussed above is equivalent to running all three +The ``run`` command, discussed above is equivalent to running all three of these in sequence. All of these commands accept a number of optional command-line arguments. The ``--help`` flag will give a complete list of these, or keep reading this page for a guide to some of the more useful ones. -Parsing Test Results +Parsing test results ==================== -KUnit tests output their results in TAP (Test Anything Protocol) format. -kunit_tool will, when running tests, parse this output and print a summary -which is much more pleasant to read. If you wish to look at the raw test -results in TAP format, you can pass the ``--raw_output`` argument. +The output of the KUnit test results are displayed in TAP (Test Anything Protocol) format. +When running tests, the kunit_tool parses this output and prints a plaintext, human-readable summary. To view the raw test results in TAP format, you can use the ``--raw_output`` argument. .. code-block:: bash ./tools/testing/kunit/kunit.py run --raw_output The raw output from test runs may contain other, non-KUnit kernel log -lines. You can see just KUnit output with ``--raw_output=kunit``: +lines. To view only the KUnit output, you can use ``--raw_output=kunit``: .. code-block:: bash ./tools/testing/kunit/kunit.py run --raw_output=kunit -If you have KUnit results in their raw TAP format, you can parse them and print +If you have KUnit results in the raw TAP format, you can parse them and print the human-readable summary with the ``parse`` command for kunit_tool. This accepts a filename for an argument, or will read from standard input. @@ -135,11 +133,11 @@ accepts a filename for an argument, or will read from standard input. This is very useful if you wish to run tests in a configuration not supported by kunit_tool (such as on real hardware, or an unsupported architecture). -Filtering Tests +Filtering tests =============== -It's possible to run only a subset of the tests built into a kernel by passing -a filter to the ``exec`` or ``run`` commands. For example, if you only wanted +It is possible to run only a subset of the tests built into a kernel by passing +a filter to the ``exec`` or ``run`` commands. For example, if you want to run KUnit resource tests, you could use: .. code-block:: bash @@ -148,15 +146,14 @@ to run KUnit resource tests, you could use: This uses the standard glob format for wildcards. -Running Tests on QEMU +Running tests on QEMU ===================== -kunit_tool supports running tests on QEMU as well as via UML (as mentioned -elsewhere). The default way of running tests on QEMU requires two flags: +kunit_tool supports running tests on QEMU as well as via UML. The default way of running tests on QEMU requires two flags: ``--arch`` Selects a collection of configs (Kconfig as well as QEMU configs - options, etc) that allow KUnit tests to be run on the specified + options and so on) that allow KUnit tests to be run on the specified architecture in a minimal way; this is usually not much slower than using UML. The architecture argument is the same as the name of the option passed to the ``ARCH`` variable used by Kbuild. Not all @@ -196,8 +193,8 @@ look something like this: --jobs=12 \ --qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py -Other Useful Options -==================== +Other useful options +====================== kunit_tool has a number of other command-line arguments which can be useful when adapting it to fit your environment or needs. @@ -228,5 +225,10 @@ Some of the more useful ones are: dependencies by adding ``CONFIG_KUNIT_ALL_TESTS=1`` to your .kunitconfig is preferable. -There are several other options (and new ones are often added), so do check +There are several other options (and new ones are often added), so do run ``--help`` if you're looking for something not mentioned here. +For more information on these options, see `Command-line-arguments +<https://www.kernel.org/doc/html/latest/dev-tools/kunit/run_wrapper.html#com…>`__ + + +. -- 2.37.1.595.g718a3a8f04-goog

2 years, 4 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror August 2022