March 2023 - Linux-kselftest-mirror

Re: [PATCH 1/8] dt-bindings: Add linux,kunit binding

by David Gow

On Fri, 10 Mar 2023 at 07:12, Stephen Boyd <sboyd(a)kernel.org> wrote: > > Quoting David Gow (2023-03-02 23:14:55) > > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd(a)kernel.org> wrote: > > > > > > Document the linux,kunit board compatible string. This board is loaded > > > into the Linux kernel when KUnit is testing devicetree dependent code. > > > > As with the series as a whole, this might need to change a little bit > > if we want to either use devicetree overlays and/or other > > architectures. > > > > That being said, I'm okay with having this until then: the only real > > topic for bikeshedding is the name. > > - Is KUnit best as a board name, or part of the vendor name? > > - Do we want to include the architecture in the name? > > Should it be "linux,kunit", "linux-kunit,uml", "linux,kunit-uml", etc? > > I think I will drop this patch. I have overlays working. I hijacked > of_core_init() to load the testcase data from drivers/of/unittest-data > and made a container node for kunit overlays to apply to. Makes sense to me, thanks! Looking forward to seeing how the overlays work in practice!

1 year, 9 months

1
0
0 0

[PATCH v4 0/4] mm: userfaultfd: refactor and add UFFDIO_CONTINUE_MODE_WP

by Axel Rasmussen

This series, currently based on 6.3-rc1, is divided into two parts: - Commits 1-3 refactor userfaultfd ioctl code without behavior changes, with the main goal of improving consistency and reducing the number of function args. - Commit 4 adds UFFDIO_CONTINUE_MODE_WP. The refactors are sorted by increasing controversial-ness, the idea being we could drop some of the refactors if they are deemed not worth it. Changelog: v3->v4: - massage the uffd_flags_t implementation to eliminate all sparse warnings - add a couple inline helpers to make uffd_flags_t usage easier - drop the refactor passing `struct uffdio_range *` around (previously 4/5) - define a temporary `struct mm_struct *` in function with >=3 `vma->vm_mm` - consistent argument order between `flags` and `pagep` - expand on the use case in patch 4/4 message v2->v3: - rebase onto 6.3-rc1 - typedef a new type for mfill flags in patch 3/5 (suggested by Nadav) v1->v2: - refactor before adding the new flag, to avoid perpetuating messiness Axel Rasmussen (4): mm: userfaultfd: rename functions for clarity + consistency mm: userfaultfd: don't pass around both mm and vma mm: userfaultfd: combine 'mode' and 'wp_copy' arguments mm: userfaultfd: add UFFDIO_CONTINUE_MODE_WP to install WP PTEs fs/userfaultfd.c | 29 ++-- include/linux/hugetlb.h | 27 ++-- include/linux/shmem_fs.h | 9 +- include/linux/userfaultfd_k.h | 68 +++++---- include/uapi/linux/userfaultfd.h | 7 + mm/hugetlb.c | 28 ++-- mm/shmem.c | 14 +- mm/userfaultfd.c | 170 +++++++++++------------ tools/testing/selftests/mm/userfaultfd.c | 4 + 9 files changed, 187 insertions(+), 169 deletions(-) -- 2.40.0.rc1.284.g88254d51c5-goog

1 year, 9 months

3
11
0 0

[PATCH v3 0/3] mm: process/cgroup ksm support

by Stefan Roesch

So far KSM can only be enabled by calling madvise for memory regions. To be able to use KSM for more workloads, KSM needs to have the ability to be enabled / disabled at the process / cgroup level. Use case 1: The madvise call is not available in the programming language. An example for this are programs with forked workloads using a garbage collected language without pointers. In such a language madvise cannot be made available. In addition the addresses of objects get moved around as they are garbage collected. KSM sharing needs to be enabled "from the outside" for these type of workloads. Use case 2: The same interpreter can also be used for workloads where KSM brings no benefit or even has overhead. We'd like to be able to enable KSM on a workload by workload basis. Use case 3: With the madvise call sharing opportunities are only enabled for the current process: it is a workload-local decision. A considerable number of sharing opportuniites may exist across multiple workloads or jobs. Only a higler level entity like a job scheduler or container can know for certain if its running one or more instances of a job. That job scheduler however doesn't have the necessary internal worklaod knowledge to make targeted madvise calls. Security concerns: In previous discussions security concerns have been brought up. The problem is that an individual workload does not have the knowledge about what else is running on a machine. Therefore it has to be very conservative in what memory areas can be shared or not. However, if the system is dedicated to running multiple jobs within the same security domain, its the job scheduler that has the knowledge that sharing can be safely enabled and is even desirable. Performance: Experiments with using UKSM have shown a capacity increase of around 20%. 1. New options for prctl system command This patch series adds two new options to the prctl system call. The first one allows to enable KSM at the process level and the second one to query the setting. The setting will be inherited by child processes. With the above setting, KSM can be enabled for the seed process of a cgroup and all processes in the cgroup will inherit the setting. 2. Changes to KSM processing When KSM is enabled at the process level, the KSM code will iterate over all the VMA's and enable KSM for the eligible VMA's. When forking a process that has KSM enabled, the setting will be inherited by the new child process. In addition when KSM is disabled for a process, KSM will be disabled for the VMA's where KSM has been enabled. 3. Add general_profit metric The general_profit metric of KSM is specified in the documentation, but not calculated. This adds the general profit metric to /sys/kernel/debug/mm/ksm. 4. Add more metrics to ksm_stat This adds the process profit and ksm type metric to /proc/<pid>/ksm_stat. 5. Add more tests to ksm_tests This adds an option to specify the merge type to the ksm_tests. This allows to test madvise and prctl KSM. It also adds a new option to query if prctl KSM has been enabled. It adds a fork test to verify that the KSM process setting is inherited by client processes. Changes: - V3: - folded patch 1 - 6 - folded patch 7 - 14 - folded patch 15 - 19 - Expanded on the use cases in the cover letter - Added a section on security concerns to the cover letter - V2: - Added use cases to the cover letter - Removed the tracing patch from the patch series and posted it as an individual patch - Refreshed repo Stefan Roesch (3): mm: add new api to enable ksm per process mm: add new KSM process and sysfs knobs selftests/mm: add new selftests for KSM Documentation/ABI/testing/sysfs-kernel-mm-ksm | 8 + Documentation/admin-guide/mm/ksm.rst | 8 +- fs/proc/base.c | 5 + include/linux/ksm.h | 19 +- include/linux/sched/coredump.h | 1 + include/uapi/linux/prctl.h | 2 + kernel/sys.c | 29 ++ mm/ksm.c | 114 +++++++- tools/include/uapi/linux/prctl.h | 2 + tools/testing/selftests/mm/Makefile | 3 +- tools/testing/selftests/mm/ksm_tests.c | 254 +++++++++++++++--- 11 files changed, 389 insertions(+), 56 deletions(-) base-commit: 234a68e24b120b98875a8b6e17a9dead277be16a -- 2.30.2

1 year, 9 months

5
15
0 0

[PATCH v4 1/3] kunit: fix bug in debugfs logs of parameterized tests

by Rae Moar

Fix bug in debugfs logs that causes individual parameterized results to not appear because the log is reinitialized (cleared) when each parameter is run. Ensure these results appear in the debugfs logs, increase log size to allow for the size of parameterized results. As a result, append lines to the log directly rather than using an intermediate variable that can cause stack size warnings due to the increased log size. Here is the debugfs log of ext4_inode_test which uses parameterized tests before the fix: KTAP version 1 # Subtest: ext4_inode_test 1..1 # Totals: pass:16 fail:0 skip:0 total:16 ok 1 ext4_inode_test As you can see, this log does not include any of the individual parametrized results. After (in combination with the next two fixes to remove extra empty line and ensure KTAP valid format): KTAP version 1 1..1 KTAP version 1 # Subtest: ext4_inode_test 1..1 KTAP version 1 # Subtest: inode_test_xtimestamp_decoding ok 1 1901-12-13 Lower bound of 32bit < 0 timestamp, no extra bits ... (the rest of the individual parameterized tests) ok 16 2446-05-10 Upper bound of 32bit >=0 timestamp. All extra # inode_test_xtimestamp_decoding: pass:16 fail:0 skip:0 total:16 ok 1 inode_test_xtimestamp_decoding # Totals: pass:16 fail:0 skip:0 total:16 ok 1 ext4_inode_test Signed-off-by: Rae Moar <rmoar(a)google.com> Reviewed-by: David Gow <davidgow(a)google.com> --- Changes from v3 -> v4: - No changes. Changes from v2 -> v3: - Fix a off-by-one bug in the kunit_log_append method. Changes from v1 -> v2: - Remove the use of the line variable in kunit_log_append that was causing stack size warnings. - Add before and after to the commit message. include/kunit/test.h | 2 +- lib/kunit/test.c | 18 ++++++++++++------ 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/include/kunit/test.h b/include/kunit/test.h index 08d3559dd703..0668d29f3453 100644 --- a/include/kunit/test.h +++ b/include/kunit/test.h @@ -34,7 +34,7 @@ DECLARE_STATIC_KEY_FALSE(kunit_running); struct kunit; /* Size of log associated with test. */ -#define KUNIT_LOG_SIZE 512 +#define KUNIT_LOG_SIZE 1500 /* Maximum size of parameter description string. */ #define KUNIT_PARAM_DESC_SIZE 128 diff --git a/lib/kunit/test.c b/lib/kunit/test.c index c9e15bb60058..c4d6304edd61 100644 --- a/lib/kunit/test.c +++ b/lib/kunit/test.c @@ -114,22 +114,27 @@ static void kunit_print_test_stats(struct kunit *test, */ void kunit_log_append(char *log, const char *fmt, ...) { - char line[KUNIT_LOG_SIZE]; va_list args; - int len_left; + int len, log_len, len_left; if (!log) return; - len_left = KUNIT_LOG_SIZE - strlen(log) - 1; + log_len = strlen(log); + len_left = KUNIT_LOG_SIZE - log_len - 1; if (len_left <= 0) return; + /* Evaluate length of line to add to log */ va_start(args, fmt); - vsnprintf(line, sizeof(line), fmt, args); + len = vsnprintf(NULL, 0, fmt, args) + 1; + va_end(args); + + /* Print formatted line to the log */ + va_start(args, fmt); + vsnprintf(log + log_len, min(len, len_left), fmt, args); va_end(args); - strncat(log, line, len_left); } EXPORT_SYMBOL_GPL(kunit_log_append); @@ -437,7 +442,6 @@ static void kunit_run_case_catch_errors(struct kunit_suite *suite, struct kunit_try_catch_context context; struct kunit_try_catch *try_catch; - kunit_init_test(test, test_case->name, test_case->log); try_catch = &test->try_catch; kunit_try_catch_init(try_catch, @@ -533,6 +537,8 @@ int kunit_run_tests(struct kunit_suite *suite) struct kunit_result_stats param_stats = { 0 }; test_case->status = KUNIT_SKIPPED; + kunit_init_test(&test, test_case->name, test_case->log); + if (!test_case->generate_params) { /* Non-parameterised test. */ kunit_run_case_catch_errors(suite, test_case, &test); base-commit: 60684c2bd35064043360e6f716d1b7c20e967b7d -- 2.40.0.rc0.216.gc4246ad0f0-goog

1 year, 9 months

2
3
0 0

[PATCH 0/2] selftests: bump timeout for firmware and kmod

by Luis Chamberlain

Shuah, I'd like this to go through your tree as this is timeout related. In order to help me help developers run tests against the components I maintain much easily I have enabled selftests support on kdevops [0]. kdevops deals with abstractsions like letting you pick virtualization or cloud solutions to run the tests using kconfig, installs all dependencies for you, and with just a few make target commands can get you the latest linux-next tested against selftests. If other find this useful and would like support for their selftests on kdevops feel free to send patches. Eventually the idea is to be able to run as many selftests in parallel using different guests for each main selftest to speed up tests. Prior to this I used to run tests manually, now the selftests helpers are used (./tools/testing/selftests/run_kselftest.sh -s) and with this the default selftest timeout is hit. This just increases that for the few selftests I help maintain where obviously its not enough anymore. Note: on the firmware side I am spotting an OOM triggered by running tests in a loop, so far I hit in the android configuration but its not clear if the issue is just for that setup. [0] https://github.com/linux-kdevops/kdevops Luis Chamberlain (2): selftests/kmod: increase the kmod timeout from 45 to 165 selftests/firmware: increase timeout from 165 to 230 tools/testing/selftests/firmware/settings | 8 +++++++- tools/testing/selftests/kmod/settings | 4 ++++ 2 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/kmod/settings -- 2.39.1

1 year, 9 months

2
8
0 0

[V2 PATCH 0/6] KVM: selftests: selftests for fd-based private memory

by Vishal Annapurve

This series implements selftests targeting the feature floated by Chao via: https://lore.kernel.org/lkml/20221202061347.1070246-10-chao.p.peng@linux.in… Below changes aim to test the fd based approach for guest private memory in context of normal (non-confidential) VMs executing on non-confidential platforms. private_mem_test.c file adds selftest to access private memory from the guest via private/shared accesses and checking if the contents can be leaked to/accessed by vmm via shared memory view before/after conversions. Updates in V2: 1) Simplified vcpu run loop implementation API 2) Removed VM creation logic from private mem library Updates in V1 (Compared to RFC v3 patches): 1) Incorporated suggestions from Sean around simplifying KVM changes 2) Addressed comments from Sean 3) Added private mem test with shared memory backed by 2MB hugepages. V1 series: https://lore.kernel.org/lkml/20221111014244.1714148-1-vannapurve@google.com… This series has dependency on following patches: 1) V10 series patches from Chao mentioned above. Github link for the patches posted as part of this series: https://github.com/vishals4gh/linux/commits/priv_memfd_selftests_v2 Vishal Annapurve (6): KVM: x86: Add support for testing private memory KVM: Selftests: Add support for private memory KVM: selftests: x86: Add IS_ALIGNED/IS_PAGE_ALIGNED helpers KVM: selftests: x86: Add helpers to execute VMs with private memory KVM: selftests: Add get_free_huge_2m_pages KVM: selftests: x86: Add selftest for private memory arch/x86/kvm/mmu/mmu_internal.h | 6 +- tools/testing/selftests/kvm/.gitignore | 1 + tools/testing/selftests/kvm/Makefile | 2 + .../selftests/kvm/include/kvm_util_base.h | 15 +- .../testing/selftests/kvm/include/test_util.h | 5 + .../kvm/include/x86_64/private_mem.h | 24 ++ .../selftests/kvm/include/x86_64/processor.h | 1 + tools/testing/selftests/kvm/lib/kvm_util.c | 58 ++++- tools/testing/selftests/kvm/lib/test_util.c | 29 +++ .../selftests/kvm/lib/x86_64/private_mem.c | 139 ++++++++++++ .../selftests/kvm/x86_64/private_mem_test.c | 212 ++++++++++++++++++ virt/kvm/Kconfig | 4 + virt/kvm/kvm_main.c | 3 +- 13 files changed, 490 insertions(+), 9 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/x86_64/private_mem.h create mode 100644 tools/testing/selftests/kvm/lib/x86_64/private_mem.c create mode 100644 tools/testing/selftests/kvm/x86_64/private_mem_test.c -- 2.39.0.rc0.267.gcb52ba06e7-goog

1 year, 9 months

5
26
0 0

[PATCH] bpf: Fix IMA test

by Roberto Sassu

From: Roberto Sassu <roberto.sassu(a)huawei.com> Commit 62622dab0a28 ("ima: return IMA digest value only when IMA_COLLECTED flag is set") caused bpf_ima_inode_hash() to refuse to give non-fresh digests. IMA test #3 assumed the old behavior, that bpf_ima_inode_hash() still returned also non-fresh digests. Correct the test by accepting both cases. If the samples returned are 1, assume that the commit above is applied and that the returned digest is fresh. If the samples returned are 2, assume that the commit above is not applied, and check both the non-fresh and fresh digest. Fixes: 62622dab0a28 ("ima: return IMA digest value only when IMA_COLLECTED flag is set") Reported by: David Vernet <void(a)manifault.com> Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> --- .../selftests/bpf/prog_tests/test_ima.c | 29 ++++++++++++++----- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/test_ima.c b/tools/testing/selftests/bpf/prog_tests/test_ima.c index b13feceb38f..810b14981c2 100644 --- a/tools/testing/selftests/bpf/prog_tests/test_ima.c +++ b/tools/testing/selftests/bpf/prog_tests/test_ima.c @@ -70,7 +70,7 @@ void test_test_ima(void) u64 bin_true_sample; char cmd[256]; - int err, duration = 0; + int err, duration = 0, fresh_digest_idx = 0; struct ima *skel = NULL; skel = ima__open_and_load(); @@ -129,7 +129,15 @@ void test_test_ima(void) /* * Test #3 * - Goal: confirm that bpf_ima_inode_hash() returns a non-fresh digest - * - Expected result: 2 samples (/bin/true: non-fresh, fresh) + * - Expected result: + * 1 sample (/bin/true: fresh) if commit 62622dab0a28 applied + * 2 samples (/bin/true: non-fresh, fresh) if commit 62622dab0a28 is + * not applied + * + * If commit 62622dab0a28 ("ima: return IMA digest value only when + * IMA_COLLECTED flag is set") is applied, bpf_ima_inode_hash() refuses + * to give a non-fresh digest, hence the correct result is 1 instead of + * 2. */ test_init(skel->bss); @@ -144,13 +152,18 @@ void test_test_ima(void) goto close_clean; err = ring_buffer__consume(ringbuf); - ASSERT_EQ(err, 2, "num_samples_or_err"); - ASSERT_NEQ(ima_hash_from_bpf[0], 0, "ima_hash"); - ASSERT_NEQ(ima_hash_from_bpf[1], 0, "ima_hash"); - ASSERT_EQ(ima_hash_from_bpf[0], bin_true_sample, "sample_equal_or_err"); + ASSERT_GE(err, 1, "num_samples_or_err"); + if (err == 2) { + ASSERT_NEQ(ima_hash_from_bpf[0], 0, "ima_hash"); + ASSERT_EQ(ima_hash_from_bpf[0], bin_true_sample, + "sample_equal_or_err"); + fresh_digest_idx = 1; + } + + ASSERT_NEQ(ima_hash_from_bpf[fresh_digest_idx], 0, "ima_hash"); /* IMA refreshed the digest. */ - ASSERT_NEQ(ima_hash_from_bpf[1], bin_true_sample, - "sample_different_or_err"); + ASSERT_NEQ(ima_hash_from_bpf[fresh_digest_idx], bin_true_sample, + "sample_equal_or_err"); /* * Test #4 -- 2.25.1

1 year, 9 months

4
6
0 0

selftests: sigaltstack: sas # exit=1 - # Bail out! SP is not on sigaltstack - on clang build

by Naresh Kamboju

kselftest: sigaltstack built with clang-16 getting failed but passed with gcc-12 build. Please find more details about test logs on clang-16 and gcc-12 and steps to reproduce locally on your machine by using tuxrun. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Test log: ---------- Linux version 6.3.0-rc1-next-20230307 (tuxmake@tuxmake) (Debian clang version 16.0.0 (++20230228093516+60692a66ced6-1~exp1~20230228093525.41), Debian LLD 16.0.0) #1 SMP PREEMPT @1678159722 ... kselftest: Running tests in sigaltstack TAP version 13 1..1 # selftests: sigaltstack: sas # # [NOTE] the stack size is 21104 # TAP version 13 # 1..3 # ok 1 Initial sigaltstack state was SS_DISABLE # Bail out! SP is not on sigaltstack # # Planned tests != run tests (3 != 1) # # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 not ok 1 selftests: sigaltstack: sas # exit=1 Links, qemu-x86_64: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230307/te… qemu-arm64: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230307/te… - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230307/te… kselftest: sigaltstack built with gcc-12 getting pass. Test log: --------- Linux version 6.3.0-rc1-next-20230307 (tuxmake@tuxmake) (aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT @1678159736 ... kselftest: Running tests in sigaltstack TAP version 13 1..1 # selftests: sigaltstack: sas # # [NOTE] the stack size is 50080 # TAP version 13 # 1..3 # ok 1 Initial sigaltstack state was SS_DISABLE # # [RUN] signal USR1 # ok 2 sigaltstack is disabled in sighandler # # [RUN] switched to user ctx # # [RUN] signal USR2 # # [OK] Stack preserved # ok 3 sigaltstack is still SS_AUTODISARM after signal # # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0 ok 1 selftests: sigaltstack: sas Links, qemu-x86_64: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230307/te… qemu-arm64: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230307/te… - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230307/te… Steps to reproduce: -------------- # To install tuxrun on your system globally: # sudo pip3 install -U tuxrun==0.37.2 # # See https://tuxrun.org/ for complete documentation. tuxrun \ --runtime podman \ --device qemu-x86_64 \ --boot-args rw \ --kernel https://storage.tuxsuite.com/public/linaro/lkft/builds/2MfXLbLsvBufVn1MrsnX… \ --modules https://storage.tuxsuite.com/public/linaro/lkft/builds/2MfXLbLsvBufVn1MrsnX… \ --rootfs https://storage.tuxboot.com/debian/bookworm/amd64/rootfs.ext4.xz \ --parameters SKIPFILE=skipfile-lkft.yaml \ --parameters KSELFTEST=https://storage.tuxsuite.com/public/linaro/lkft/builds/2MfXLbLsvB… \ --image docker.io/lavasoftware/lava-dispatcher:2023.01.0020.gc1598238f \ --tests kselftest-sigaltstack \ --timeouts boot=15 -- Linaro LKFT https://lkft.linaro.org

1 year, 9 months

4
4
0 0

[PATCH v3 0/5] mm: userfaultfd: refactor and add UFFDIO_CONTINUE_MODE_WP

by Axel Rasmussen

This series, currently based on 6.3-rc1, is divided into two parts: - Commits 1-4 refactor userfaultfd ioctl code without behavior changes, with the main goal of improving consistency and reducing the number of function args. - Commit 5 adds UFFDIO_CONTINUE_MODE_WP. The refactors are sorted by increasing controversial-ness, the idea being we could drop some of the refactors if they are deemed not worth it. Changelog: v2->v3: - rebase onto 6.3-rc1 - typedef a new type for mfill flags in patch 3/5 (suggested by Nadav) v1->v2: - refactor before adding the new flag, to avoid perpetuating messiness Axel Rasmussen (5): mm: userfaultfd: rename functions for clarity + consistency mm: userfaultfd: don't pass around both mm and vma mm: userfaultfd: combine 'mode' and 'wp_copy' arguments mm: userfaultfd: don't separate addr + len arguments mm: userfaultfd: add UFFDIO_CONTINUE_MODE_WP to install WP PTEs fs/userfaultfd.c | 120 +++++------- include/linux/hugetlb.h | 27 ++- include/linux/shmem_fs.h | 9 +- include/linux/userfaultfd_k.h | 61 +++--- include/uapi/linux/userfaultfd.h | 7 + mm/hugetlb.c | 34 ++-- mm/shmem.c | 14 +- mm/userfaultfd.c | 235 +++++++++++------------ tools/testing/selftests/mm/userfaultfd.c | 4 + 9 files changed, 247 insertions(+), 264 deletions(-) -- 2.40.0.rc0.216.gc4246ad0f0-goog

1 year, 9 months

4
18
0 0

[PATCH 2/2] selftests/clone3: test clone3 with CLONE_NEWTIME

by Tobias Klauser

Verify that clone3 can be called successfully with CLONE_NEWTIME in flags. Cc: Andrey Vagin <avagin(a)openvz.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Tobias Klauser <tklauser(a)distanz.ch> --- tools/testing/selftests/clone3/clone3.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/clone3/clone3.c b/tools/testing/selftests/clone3/clone3.c index cd4582129c7d..4fce46afe6db 100644 --- a/tools/testing/selftests/clone3/clone3.c +++ b/tools/testing/selftests/clone3/clone3.c @@ -195,5 +195,8 @@ int main(int argc, char *argv[]) test_clone3(CLONE_NEWPID, getpagesize() + 8, -E2BIG, CLONE3_ARGS_NO_TEST); + /* Do a clone3() in a new time namespace */ + test_clone3(CLONE_NEWTIME, 0, 0, CLONE3_ARGS_NO_TEST); + return !ksft_get_fail_cnt() ? ksft_exit_pass() : ksft_exit_fail(); } -- 2.39.1

1 year, 9 months

1
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror March 2023