December 2019 - Linux-kselftest-mirror

[PATCH kselftest/test] kunit: Always print actual pointer values in asserts

by David Gow

KUnit assertions and expectations will print the values being tested. If these are pointers (e.g., KUNIT_EXPECT_PTR_EQ(test, a, b)), these pointers are currently printed with the %pK format specifier, which -- to prevent information leaks which may compromise, e.g., ASLR -- are often either hashed or replaced with ____ptrval____ or similar, making debugging tests difficult. By replacing %pK with %px as Documentation/core-api/printk-formats.rst suggests, we disable this security feature for KUnit assertions and expectations, allowing the actual pointer values to be printed. Given that KUnit is not intended for use in production kernels, and the pointers are only printed on failing tests, this seems like a worthwhile tradeoff. Signed-off-by: David Gow <davidgow(a)google.com> --- This seems like the best way of solving this problem to me, but if anyone has a better solution I'd love to hear it. Note also that this does trigger two checkpatch.pl warnings, which warn that the change will potentially cause the kernel memory layout to be exposed. Since that's the whole point of the change, they probably sohuld stay there. lib/kunit/assert.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/kunit/assert.c b/lib/kunit/assert.c index 86013d4cf891..a87960409bd4 100644 --- a/lib/kunit/assert.c +++ b/lib/kunit/assert.c @@ -110,10 +110,10 @@ void kunit_binary_ptr_assert_format(const struct kunit_assert *assert, binary_assert->left_text, binary_assert->operation, binary_assert->right_text); - string_stream_add(stream, "\t\t%s == %pK\n", + string_stream_add(stream, "\t\t%s == %px\n", binary_assert->left_text, binary_assert->left_value); - string_stream_add(stream, "\t\t%s == %pK", + string_stream_add(stream, "\t\t%s == %px", binary_assert->right_text, binary_assert->right_value); kunit_assert_print_msg(assert, stream); -- 2.24.0.432.g9d3f5f5b63-goog

4 years, 1 month

3
4
0 0

syzkaller reproducers

by Dmitry Vyukov

Hi Shuah, We discussed collecting and uploading all syzkaller reproducers somewhere. You wanted to see how they look. I've uploaded all current reproducers here: https://github.com/dvyukov/syzkaller-repros Minimalistic build/run scripts are included. +some testing mailing lists too as this can be used as a test suite If you have any potential uses for this, you are welcome to use it. But then we probably need to find some more official and shared place for them than my private github. The test programs can also be bulk updated if necessary, because all of this is auto-generated. Thanks

4 years, 1 month

5
24
0 0

[PATCH 0/3] riscv: add support for restartable sequence

by Vincent Chen

Add RSEQ, restartable sequence, support and related selftest to RISCV. The Kconfig option HAVE_REGS_AND_STACK_ACCESS_API is also required by RSEQ because RSEQ will modify the content of pt_regs.sepc through instruction_pointer_set() during the fixup procedure. In order to select the config HAVE_REGS_AND_STACK_ACCESS_API, the missing APIs for accessing pt_regs are also added in this patch set. The relevant RSEQ tests in kselftest require the Binutils patch "RISC-V: Fix linker problems with TLS copy relocs" to avoid placing PREINIT_ARRAY and TLS variable of librseq.so at the same address. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=3e7bd7f… A segmental fault will happen if the Binutils misses this patch. Vincent Chen (3): riscv: add required functions to enable HAVE_REGS_AND_STACK_ACCESS_API riscv: Add support for restartable sequence rseq/selftests: Add support for riscv arch/riscv/Kconfig | 2 + arch/riscv/include/asm/ptrace.h | 29 +- arch/riscv/kernel/entry.S | 4 + arch/riscv/kernel/ptrace.c | 99 +++++ arch/riscv/kernel/signal.c | 3 + tools/testing/selftests/rseq/param_test.c | 23 ++ tools/testing/selftests/rseq/rseq-riscv.h | 622 ++++++++++++++++++++++++++++++ tools/testing/selftests/rseq/rseq.h | 2 + 8 files changed, 783 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/rseq/rseq-riscv.h -- 2.7.4

4 years, 1 month

3
8
0 0

[RFC v1 0/6] kunit: create a centralized executor to dispatch all KUnit tests

by Brendan Higgins

## TL;DR This patchset adds a centralized executor to dispatch tests rather than relying on late_initcall to schedule each test suite separately along with a couple of new features that depend on it. ## What am I trying to do? Conceptually, I am trying to provide a mechanism by which test suites can be grouped together so that they can be reasoned about collectively. The last two patches in this series add features which depend on this: RFC 5/6 Prints out a test plan right before KUnit tests are run[1]; this is valuable because it makes it possible for a test harness to detect whether the number of tests run matches the number of tests expected to be run, ensuring that no tests silently failed. RFC 6/6 Add a new kernel command-line option which allows the user to specify that the kernel poweroff, halt, or reboot after completing all KUnit tests; this is very handy for running KUnit tests on UML or a VM so that the UML/VM process exits cleanly immediately after running all tests without needing a special initramfs. In addition, by dispatching tests from a single location, we can guarantee that all KUnit tests run after late_init is complete, which was a concern during the initial KUnit patchset review (this has not been a problem in practice, but resolving with certainty is nevertheless desirable). Other use cases for this exist, but the above features should provide an idea of the value that this could provide. ## What work remains to be done? These patches were based on patches in our non-upstream branch[2], so we have a pretty good idea that they are useable as presented; nevertheless, some of the changes done in this patchset could *definitely* use some review by subsystem experts (linker scripts, init, etc), and will likely change a lot after getting feedback. The biggest thing that I know will require additional attention is integrating this patchset with the KUnit module support patchset[3]. I have not even attempted to build these patches on top of the module support patches as I would like to get people's initial thoughts first (especially Alan's :-) ). I think that making these patches work with module support should be fairly straight forward, nevertheless. Brendan Higgins (5): vmlinux.lds.h: add linker section for KUnit test suites arch: um: add linker section for KUnit test suites kunit: test: create a single centralized executor for all tests init: main: add KUnit to kernel init kunit: test: add test plan to KUnit TAP format David Gow (1): kunit: Add 'kunit_shutdown' option arch/um/include/asm/common.lds.S | 4 + include/asm-generic/vmlinux.lds.h | 8 ++ include/kunit/test.h | 16 ++-- init/main.c | 4 + lib/kunit/Makefile | 3 +- lib/kunit/executor.c | 74 ++++++++++++++++++ lib/kunit/test.c | 11 --- tools/testing/kunit/kunit_kernel.py | 2 +- tools/testing/kunit/kunit_parser.py | 76 +++++++++++++++---- .../test_is_test_passed-all_passed.log | 1 + .../test_data/test_is_test_passed-crash.log | 1 + .../test_data/test_is_test_passed-failure.log | 1 + 12 files changed, 170 insertions(+), 31 deletions(-) create mode 100644 lib/kunit/executor.c [1]: https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-… [2]: https://kunit-review.googlesource.com/c/linux/+/1037 [3]: https://patchwork.kernel.org/project/linux-kselftest/list/?series=211727 -- 2.24.1.735.g03f4e72817-goog

4 years, 1 month

6
28
0 0

[PATCH v5 00/19] x86/cpu: Clean up handling of VMX features

by Sean Christopherson

Clean up a handful of interrelated warts in the kernel's handling of VMX: - Enable VMX in IA32_FEATURE_CONTROL during boot instead of on-demand during KVM load to avoid future contention over IA32_FEATURE_CONTROL. - Rework VMX feature reporting so that it is accurate and up-to-date, now and in the future. - Consolidate code across CPUs that support VMX. This series stems from two separate but related issues. The first issue, pointed out by Boris in the SGX enabling series[*], is that the kernel currently doesn't ensure the IA32_FEATURE_CONTROL MSR is configured during boot. The second issue is that the kernel's reporting of VMX features is stale, potentially inaccurate, and difficult to maintain. v5: - Rebase to tip/master, ec7b10f2d023 ("Merge branch 'x86/cleanups'") - Fix a missing IA32_FEAT_CTL change in the idle driver (which amusingly reads the MSR to deal with SGX). [kbuild test robot] - Tweak the displayed names for VMX flags. [Boris, Paolo, Liran] - Add a comment above the raw rdmsr() calls in the VMX feature flag parsing. [Boris] - Fix a few changelog typos. [Boris] - Use VMX_F() instead of F() for the VMX flag extraction macro. [Boris] - Drop 'PROC' from the PRIMARY_CTLS and SECONDARY_CTLS enums to keep line lengths sane. - Keep the pr_fmt at the top of feat_ctl.c when the flag populating code is introduced (previously got buried in the middle of the file). v4: - Rebase to tip/master, 8a1b070333f4 ("Merge branch 'WIP.x86/mm'") - Rename everything feature control related to IA32_FEAT_CTL. [Boris] - Minor coding style tweaks [Boris and Jarkko]. - Print VMX feature flags in "vmx flags" to avoid polluting "flags", but keep printing the current synthetic VMX in "flags" so as not to break the ABI. [Boris] - Don't bother printing an error message in the extremely unlikely event VMX is supported but IA32_FEAT_CTL doesn't exist. [Boris] - Beef up a few changelogs and comments. [Boris] - Add a comment in the LMCE code for the new WARN. [Jarkko] - Check CONFIG_KVM_INTEL instead of CONFIG_KVM when deciding whether or not to enable VMX. - Add a patch to introduce X86_FEATURE_MSR_IA32_FEAT_CTL. - Dropped Jim's Reviewed-by from a few KVM patches due to the above addition. v3: - Rebase to tip/master, ceceaf1f12ba ("Merge branch 'WIP.x86/cleanups'"). - Rename the feature control MSR bit defines [Boris]. - Rewrite the error message displayed when reading feature control MSR faults on a VMX capable CPU to explicitly state that it's likely a hardware or hypervisor issue [Boris]. - Collect a Reviewed-by for the LMCE change [Boris]. - Enable VMX in feature control (if it's unlocked) if and only if KVM is enabled [Paolo]. - Remove a big pile of redudant MSR defines from the KVM selftests that was discovered when renaming the feature control defines. - Fix a changelog typo [Boris]. v2: - Rebase to latest tip/x86/cpu (1edae1ae6258, "x86/Kconfig: Enforce...) - Collect Jim's reviews. - Fix a typo in setting of EPT capabilities [TonyWWang-oc]. - Remove defines for reserved VMX feature flags [Paolo]. - Print the VMX features under "flags" and maintain all existing names to be backward compatible with the ABI [Paolo]. - Create aggregate APIC features to report FLEXPRIORITY and APICV, so that the full feature *and* their associated individual features are printed, e.g. to aid in recognizing why an APIC feature isn't being used. - Fix a few copy paste errors in changelogs. v1 cover letter: == IA32_FEATURE_CONTROL == Lack of IA32_FEATURE_CONTROL configuration during boot isn't a functional issue in the current kernel as the majority of platforms set and lock IA32_FEATURE_CONTROL in firmware. And when the MSR is left unlocked, KVM is the only subsystem that writes IA32_FEATURE_CONTROL. That will change if/when SGX support is enabled, as SGX will also want to fully enable itself when IA32_FEATURE_CONTROL is unlocked. == VMX Feature Reporting == VMX features are not enumerated via CPUID, but instead are enumerated through VMX MSRs. As a result, new VMX features are not automatically reported via /proc/cpuinfo. An attempt was made long ago to report interesting and/or meaningful VMX features by synthesizing select features into a Linux-defined cpufeatures word. Synthetic feature flags worked for the initial purpose, but the existence of the synthetic flags was forgotten almost immediately, e.g. only one new flag (EPT A/D) has been added in the the decade since the synthetic VMX features were introduced, while VMX and KVM have gained support for many new features. Placing the synthetic flags in x86_capability also allows them to be queried via cpu_has() and company, which is misleading as the flags exist purely for reporting via /proc/cpuinfo. KVM, the only in-kernel user of VMX, ignores the flags. Last but not least, VMX features are reported in /proc/cpuinfo even when VMX is unusable due to lack of enabling in IA32_FEATURE_CONTROL. == Caveats == All of the testing of non-standard flows was done in a VM, as I don't have a system that leaves IA32_FEATURE_CONTROL unlocked, or locks it with VMX disabled. The Centaur and Zhaoxin changes are somewhat speculative, as I haven't confirmed they actually support IA32_FEATURE_CONTROL, or that they want to gain "official" KVM support. I assume they unofficially support KVM given that both CPUs went through the effort of enumerating VMX features. That in turn would require them to support IA32_FEATURE_CONTROL since KVM will fault and refuse to load if the MSR doesn't exist. [*] https://lkml.kernel.org/r/20190925085156.GA3891@zn.tnic Sean Christopherson (19): x86/msr-index: Clean up bit defines for IA32_FEATURE_CONTROL MSR selftests: kvm: Replace manual MSR defs with common msr-index.h tools arch x86: Sync msr-index.h from kernel sources x86/intel: Initialize IA32_FEAT_CTL MSR at boot x86/mce: WARN once if IA32_FEAT_CTL MSR is left unlocked x86/centaur: Use common IA32_FEAT_CTL MSR initialization x86/zhaoxin: Use common IA32_FEAT_CTL MSR initialization x86/cpu: Clear VMX feature flag if VMX is not fully enabled x86/vmx: Introduce VMX_FEATURES_* x86/cpu: Detect VMX features on Intel, Centaur and Zhaoxin CPUs x86/cpu: Print VMX flags in /proc/cpuinfo using VMX_FEATURES_* x86/cpu: Set synthetic VMX cpufeatures during init_ia32_feat_ctl() x86/cpufeatures: Add flag to track whether MSR IA32_FEAT_CTL is configured KVM: VMX: Drop initialization of IA32_FEAT_CTL MSR KVM: VMX: Use VMX feature flag to query BIOS enabling KVM: VMX: Check for full VMX support when verifying CPU compatibility KVM: VMX: Use VMX_FEATURE_* flags to define VMCS control bits perf/x86: Provide stubs of KVM helpers for non-Intel CPUs KVM: VMX: Allow KVM_INTEL when building for Centaur and/or Zhaoxin CPUs MAINTAINERS | 2 +- arch/x86/Kconfig.cpu | 8 + arch/x86/boot/mkcpustr.c | 1 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 14 +- arch/x86/include/asm/perf_event.h | 22 +- arch/x86/include/asm/processor.h | 4 + arch/x86/include/asm/vmx.h | 105 +-- arch/x86/include/asm/vmxfeatures.h | 86 +++ arch/x86/kernel/cpu/Makefile | 6 +- arch/x86/kernel/cpu/centaur.c | 35 +- arch/x86/kernel/cpu/common.c | 3 + arch/x86/kernel/cpu/cpu.h | 4 + arch/x86/kernel/cpu/feat_ctl.c | 144 ++++ arch/x86/kernel/cpu/intel.c | 49 +- arch/x86/kernel/cpu/mce/intel.c | 15 +- arch/x86/kernel/cpu/mkcapflags.sh | 15 +- arch/x86/kernel/cpu/proc.c | 15 + arch/x86/kernel/cpu/zhaoxin.c | 35 +- arch/x86/kvm/Kconfig | 10 +- arch/x86/kvm/vmx/nested.c | 4 +- arch/x86/kvm/vmx/vmx.c | 67 +- arch/x86/kvm/vmx/vmx.h | 2 +- arch/x86/kvm/x86.c | 2 +- drivers/idle/intel_idle.c | 2 +- tools/arch/x86/include/asm/msr-index.h | 14 +- tools/power/x86/turbostat/turbostat.c | 4 +- tools/testing/selftests/kvm/Makefile | 4 +- .../selftests/kvm/include/x86_64/processor.h | 726 +----------------- tools/testing/selftests/kvm/lib/x86_64/vmx.c | 8 +- 30 files changed, 420 insertions(+), 987 deletions(-) create mode 100644 arch/x86/include/asm/vmxfeatures.h create mode 100644 arch/x86/kernel/cpu/feat_ctl.c -- 2.24.1

4 years, 2 months

4
43
0 0

[PATCH 0/7] firmware: add partial read support in request_firmware_into_buf

by Scott Branden

This patch series adds partial read support in request_firmware_into_buf. In order to accept the enhanced API it has been requested that kernel selftests and upstreamed driver utilize the API enhancement and so are included in this patch series. Also, no tests existed for existing request_firmware_into_buf kernel API. Therefore tests have been created and submitted upstream here: "[PATCH v2 0/2] firmware: selftest for request_firmware_into_buf" https://lkml.org/lkml/2019/8/22/1367 The firmware selftests patches here require those patches to be applied first in order for the firmware selftest patches in this series to be valid. Finally, in this patch series is the addition of a new Broadcom Valkyrie driver utilizing the new request_firmware_into_buf enhanced API. Scott Branden (7): fs: introduce kernel_pread_file* support firmware: add offset to request_firmware_into_buf test_firmware: add partial read support for request_firmware_into_buf selftests: firmware: Test partial file reads of request_firmware_into_buf bcm-vk: add bcm_vk UAPI misc: bcm-vk: add Broadcom Valkyrie driver MAINTAINERS: bcm-vk: Add maintainer for Broadcom Valkyrie Driver MAINTAINERS | 7 + drivers/base/firmware_loader/firmware.h | 5 + drivers/base/firmware_loader/main.c | 49 +- drivers/misc/Kconfig | 1 + drivers/misc/Makefile | 1 + drivers/misc/bcm-vk/Kconfig | 16 + drivers/misc/bcm-vk/Makefile | 7 + drivers/misc/bcm-vk/README | 29 + drivers/misc/bcm-vk/bcm_vk.h | 229 +++ drivers/misc/bcm-vk/bcm_vk_dev.c | 1558 +++++++++++++++++ drivers/misc/bcm-vk/bcm_vk_msg.c | 963 ++++++++++ drivers/misc/bcm-vk/bcm_vk_msg.h | 169 ++ drivers/misc/bcm-vk/bcm_vk_sg.c | 273 +++ drivers/misc/bcm-vk/bcm_vk_sg.h | 60 + drivers/soc/qcom/mdt_loader.c | 7 +- fs/exec.c | 77 +- include/linux/firmware.h | 8 +- include/linux/fs.h | 15 + include/uapi/linux/misc/bcm_vk.h | 88 + lib/test_firmware.c | 139 +- .../selftests/firmware/fw_filesystem.sh | 80 + 21 files changed, 3744 insertions(+), 37 deletions(-) create mode 100644 drivers/misc/bcm-vk/Kconfig create mode 100644 drivers/misc/bcm-vk/Makefile create mode 100644 drivers/misc/bcm-vk/README create mode 100644 drivers/misc/bcm-vk/bcm_vk.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h create mode 100644 include/uapi/linux/misc/bcm_vk.h -- 2.17.1

4 years, 2 months

7
35
0 0

[PATCH] selftests: settings: tests can be in subsubdirs

by Matthieu Baerts

Commit 852c8cbf34d3 (selftests/kselftest/runner.sh: Add 45 second timeout per test) adds support for a new per-test-directory "settings" file. But this only works for tests not in a sub-subdirectories, e.g. - tools/testing/selftests/rtc (rtc) is OK, - tools/testing/selftests/net/mptcp (net/mptcp) is not. We have to increase the timeout for net/mptcp tests which are not upstreamed yet but this fix is valid for other tests if they need to add a "settings" file, see the full list with: tools/testing/selftests/*/*/**/Makefile Note that this patch changes the text header message printed at the end of the execution but this text is modified only for the tests that are in sub-subdirectories, e.g. ok 1 selftests: net/mptcp: mptcp_connect.sh Before we had: ok 1 selftests: mptcp: mptcp_connect.sh But showing the full target name is probably better, just in case a subsubdir has the same name as another one in another subdirectory. Fixes: 852c8cbf34d3 (selftests/kselftest/runner.sh: Add 45 second timeout per test) Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> --- 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 84de7bc74f2c..0d7a89901ef7 100644 --- a/tools/testing/selftests/kselftest/runner.sh +++ b/tools/testing/selftests/kselftest/runner.sh @@ -90,7 +90,7 @@ run_one() run_many() { echo "TAP version 13" - DIR=$(basename "$PWD") + DIR="${PWD#${BASE_DIR}/}" test_num=0 total=$(echo "$@" | wc -w) echo "1..$total" -- 2.20.1

4 years, 3 months

3
5
0 0

[PATCH v9 1/8] hugetlb_cgroup: Add hugetlb_cgroup reservation counter

by Mina Almasry

These counters will track hugetlb reservations rather than hugetlb memory faulted in. This patch only adds the counter, following patches add the charging and uncharging of the counter. This is patch 1 of an 8 patch series. Problem: Currently tasks attempting to allocate more hugetlb memory than is available get a failure at mmap/shmget time. This is thanks to Hugetlbfs Reservations [1]. However, if a task attempts to allocate hugetlb memory only more than its hugetlb_cgroup limit allows, the kernel will allow the mmap/shmget call, but will SIGBUS the task when it attempts to fault the memory in. We have developers interested in using hugetlb_cgroups, and they have expressed dissatisfaction regarding this behavior. We'd like to improve this behavior such that tasks violating the hugetlb_cgroup limits get an error on mmap/shmget time, rather than getting SIGBUS'd when they try to fault the excess memory in. The underlying problem is that today's hugetlb_cgroup accounting happens at hugetlb memory *fault* time, rather than at *reservation* time. Thus, enforcing the hugetlb_cgroup limit only happens at fault time, and the offending task gets SIGBUS'd. Proposed Solution: A new page counter named hugetlb.xMB.reservation_[limit|usage]_in_bytes. This counter has slightly different semantics than hugetlb.xMB.[limit|usage]_in_bytes: - While usage_in_bytes tracks all *faulted* hugetlb memory, reservation_usage_in_bytes tracks all *reserved* hugetlb memory and hugetlb memory faulted in without a prior reservation. - If a task attempts to reserve more memory than limit_in_bytes allows, the kernel will allow it to do so. But if a task attempts to reserve more memory than reservation_limit_in_bytes, the kernel will fail this reservation. This proposal is implemented in this patch series, with tests to verify functionality and show the usage. We also added cgroup-v2 support to hugetlb_cgroup so that the new use cases can be extended to v2. Alternatives considered: 1. A new cgroup, instead of only a new page_counter attached to the existing hugetlb_cgroup. Adding a new cgroup seemed like a lot of code duplication with hugetlb_cgroup. Keeping hugetlb related page counters under hugetlb_cgroup seemed cleaner as well. 2. Instead of adding a new counter, we considered adding a sysctl that modifies the behavior of hugetlb.xMB.[limit|usage]_in_bytes, to do accounting at reservation time rather than fault time. Adding a new page_counter seems better as userspace could, if it wants, choose to enforce different cgroups differently: one via limit_in_bytes, and another via reservation_limit_in_bytes. This could be very useful if you're transitioning how hugetlb memory is partitioned on your system one cgroup at a time, for example. Also, someone may find usage for both limit_in_bytes and reservation_limit_in_bytes concurrently, and this approach gives them the option to do so. Testing: - Added tests passing. - Used libhugetlbfs for regression testing. [1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html Signed-off-by: Mina Almasry <almasrymina(a)google.com> Acked-by: Hillf Danton <hdanton(a)sina.com> --- include/linux/hugetlb.h | 4 +- mm/hugetlb_cgroup.c | 116 +++++++++++++++++++++++++++++++++++----- 2 files changed, 106 insertions(+), 14 deletions(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 1e897e4168ac1..dea6143aa0685 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -432,8 +432,8 @@ struct hstate { unsigned int surplus_huge_pages_node[MAX_NUMNODES]; #ifdef CONFIG_CGROUP_HUGETLB /* cgroup control files */ - struct cftype cgroup_files_dfl[5]; - struct cftype cgroup_files_legacy[5]; + struct cftype cgroup_files_dfl[7]; + struct cftype cgroup_files_legacy[9]; #endif char name[HSTATE_NAME_LEN]; }; diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c index e434b05416c68..35415af9ed26f 100644 --- a/mm/hugetlb_cgroup.c +++ b/mm/hugetlb_cgroup.c @@ -36,6 +36,11 @@ struct hugetlb_cgroup { */ struct page_counter hugepage[HUGE_MAX_HSTATE]; + /* + * the counter to account for hugepage reservations from hugetlb. + */ + struct page_counter reserved_hugepage[HUGE_MAX_HSTATE]; + atomic_long_t events[HUGE_MAX_HSTATE][HUGETLB_NR_MEMORY_EVENTS]; atomic_long_t events_local[HUGE_MAX_HSTATE][HUGETLB_NR_MEMORY_EVENTS]; @@ -55,6 +60,14 @@ struct hugetlb_cgroup { static struct hugetlb_cgroup *root_h_cgroup __read_mostly; +static inline struct page_counter * +hugetlb_cgroup_get_counter(struct hugetlb_cgroup *h_cg, int idx, bool reserved) +{ + if (reserved) + return &h_cg->reserved_hugepage[idx]; + return &h_cg->hugepage[idx]; +} + static inline struct hugetlb_cgroup *hugetlb_cgroup_from_css(struct cgroup_subsys_state *s) { @@ -295,28 +308,42 @@ void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages, enum { RES_USAGE, + RES_RESERVATION_USAGE, RES_LIMIT, + RES_RESERVATION_LIMIT, RES_MAX_USAGE, + RES_RESERVATION_MAX_USAGE, RES_FAILCNT, + RES_RESERVATION_FAILCNT, }; static u64 hugetlb_cgroup_read_u64(struct cgroup_subsys_state *css, struct cftype *cft) { struct page_counter *counter; + struct page_counter *reserved_counter; struct hugetlb_cgroup *h_cg = hugetlb_cgroup_from_css(css); counter = &h_cg->hugepage[MEMFILE_IDX(cft->private)]; + reserved_counter = &h_cg->reserved_hugepage[MEMFILE_IDX(cft->private)]; switch (MEMFILE_ATTR(cft->private)) { case RES_USAGE: return (u64)page_counter_read(counter) * PAGE_SIZE; + case RES_RESERVATION_USAGE: + return (u64)page_counter_read(reserved_counter) * PAGE_SIZE; case RES_LIMIT: return (u64)counter->max * PAGE_SIZE; + case RES_RESERVATION_LIMIT: + return (u64)reserved_counter->max * PAGE_SIZE; case RES_MAX_USAGE: return (u64)counter->watermark * PAGE_SIZE; + case RES_RESERVATION_MAX_USAGE: + return (u64)reserved_counter->watermark * PAGE_SIZE; case RES_FAILCNT: return counter->failcnt; + case RES_RESERVATION_FAILCNT: + return reserved_counter->failcnt; default: BUG(); } @@ -338,10 +365,16 @@ static int hugetlb_cgroup_read_u64_max(struct seq_file *seq, void *v) 1 << huge_page_order(&hstates[idx])); switch (MEMFILE_ATTR(cft->private)) { + case RES_RESERVATION_USAGE: + counter = &h_cg->reserved_hugepage[idx]; + /* Fall through. */ case RES_USAGE: val = (u64)page_counter_read(counter); seq_printf(seq, "%llu\n", val * PAGE_SIZE); break; + case RES_RESERVATION_LIMIT: + counter = &h_cg->reserved_hugepage[idx]; + /* Fall through. */ case RES_LIMIT: val = (u64)counter->max; if (val == limit) @@ -365,6 +398,7 @@ static ssize_t hugetlb_cgroup_write(struct kernfs_open_file *of, int ret, idx; unsigned long nr_pages; struct hugetlb_cgroup *h_cg = hugetlb_cgroup_from_css(of_css(of)); + bool reserved = false; if (hugetlb_cgroup_is_root(h_cg)) /* Can't set limit on root */ return -EINVAL; @@ -378,9 +412,14 @@ static ssize_t hugetlb_cgroup_write(struct kernfs_open_file *of, nr_pages = round_down(nr_pages, 1 << huge_page_order(&hstates[idx])); switch (MEMFILE_ATTR(of_cft(of)->private)) { + case RES_RESERVATION_LIMIT: + reserved = true; + /* Fall through. */ case RES_LIMIT: mutex_lock(&hugetlb_limit_mutex); - ret = page_counter_set_max(&h_cg->hugepage[idx], nr_pages); + ret = page_counter_set_max(hugetlb_cgroup_get_counter(h_cg, idx, + reserved), + nr_pages); mutex_unlock(&hugetlb_limit_mutex); break; default: @@ -406,18 +445,26 @@ static ssize_t hugetlb_cgroup_reset(struct kernfs_open_file *of, char *buf, size_t nbytes, loff_t off) { int ret = 0; - struct page_counter *counter; + struct page_counter *counter, *reserved_counter; struct hugetlb_cgroup *h_cg = hugetlb_cgroup_from_css(of_css(of)); counter = &h_cg->hugepage[MEMFILE_IDX(of_cft(of)->private)]; + reserved_counter = + &h_cg->reserved_hugepage[MEMFILE_IDX(of_cft(of)->private)]; switch (MEMFILE_ATTR(of_cft(of)->private)) { case RES_MAX_USAGE: page_counter_reset_watermark(counter); break; + case RES_RESERVATION_MAX_USAGE: + page_counter_reset_watermark(reserved_counter); + break; case RES_FAILCNT: counter->failcnt = 0; break; + case RES_RESERVATION_FAILCNT: + reserved_counter->failcnt = 0; + break; default: ret = -EINVAL; break; @@ -472,7 +519,7 @@ static void __init __hugetlb_cgroup_file_dfl_init(int idx) struct hstate *h = &hstates[idx]; /* format the size */ - mem_fmt(buf, 32, huge_page_size(h)); + mem_fmt(buf, sizeof(buf), huge_page_size(h)); /* Add the limit file */ cft = &h->cgroup_files_dfl[0]; @@ -482,15 +529,30 @@ static void __init __hugetlb_cgroup_file_dfl_init(int idx) cft->write = hugetlb_cgroup_write_dfl; cft->flags = CFTYPE_NOT_ON_ROOT; - /* Add the current usage file */ + /* Add the reservation limit file */ cft = &h->cgroup_files_dfl[1]; + snprintf(cft->name, MAX_CFTYPE_NAME, "%s.reservation_max", buf); + cft->private = MEMFILE_PRIVATE(idx, RES_RESERVATION_LIMIT); + cft->seq_show = hugetlb_cgroup_read_u64_max; + cft->write = hugetlb_cgroup_write_dfl; + cft->flags = CFTYPE_NOT_ON_ROOT; + + /* Add the current usage file */ + cft = &h->cgroup_files_dfl[2]; snprintf(cft->name, MAX_CFTYPE_NAME, "%s.current", buf); cft->private = MEMFILE_PRIVATE(idx, RES_USAGE); cft->seq_show = hugetlb_cgroup_read_u64_max; cft->flags = CFTYPE_NOT_ON_ROOT; + /* Add the current reservation usage file */ + cft = &h->cgroup_files_dfl[3]; + snprintf(cft->name, MAX_CFTYPE_NAME, "%s.reservation_current", buf); + cft->private = MEMFILE_PRIVATE(idx, RES_RESERVATION_USAGE); + cft->seq_show = hugetlb_cgroup_read_u64_max; + cft->flags = CFTYPE_NOT_ON_ROOT; + /* Add the events file */ - cft = &h->cgroup_files_dfl[2]; + cft = &h->cgroup_files_dfl[4]; snprintf(cft->name, MAX_CFTYPE_NAME, "%s.events", buf); cft->private = MEMFILE_PRIVATE(idx, 0); cft->seq_show = hugetlb_events_show; @@ -498,7 +560,7 @@ static void __init __hugetlb_cgroup_file_dfl_init(int idx) cft->flags = CFTYPE_NOT_ON_ROOT; /* Add the events.local file */ - cft = &h->cgroup_files_dfl[3]; + cft = &h->cgroup_files_dfl[5]; snprintf(cft->name, MAX_CFTYPE_NAME, "%s.events.local", buf); cft->private = MEMFILE_PRIVATE(idx, 0); cft->seq_show = hugetlb_events_local_show; @@ -507,7 +569,7 @@ static void __init __hugetlb_cgroup_file_dfl_init(int idx) cft->flags = CFTYPE_NOT_ON_ROOT; /* NULL terminate the last cft */ - cft = &h->cgroup_files_dfl[4]; + cft = &h->cgroup_files_dfl[6]; memset(cft, 0, sizeof(*cft)); WARN_ON(cgroup_add_dfl_cftypes(&hugetlb_cgrp_subsys, @@ -530,28 +592,58 @@ static void __init __hugetlb_cgroup_file_legacy_init(int idx) cft->read_u64 = hugetlb_cgroup_read_u64; cft->write = hugetlb_cgroup_write_legacy; - /* Add the usage file */ + /* Add the reservation limit file */ cft = &h->cgroup_files_legacy[1]; + snprintf(cft->name, MAX_CFTYPE_NAME, "%s.reservation_limit_in_bytes", + buf); + cft->private = MEMFILE_PRIVATE(idx, RES_RESERVATION_LIMIT); + cft->read_u64 = hugetlb_cgroup_read_u64; + cft->write = hugetlb_cgroup_write_legacy; + + /* Add the usage file */ + cft = &h->cgroup_files_legacy[2]; snprintf(cft->name, MAX_CFTYPE_NAME, "%s.usage_in_bytes", buf); cft->private = MEMFILE_PRIVATE(idx, RES_USAGE); cft->read_u64 = hugetlb_cgroup_read_u64; + /* Add the reservation usage file */ + cft = &h->cgroup_files_legacy[3]; + snprintf(cft->name, MAX_CFTYPE_NAME, "%s.reservation_usage_in_bytes", + buf); + cft->private = MEMFILE_PRIVATE(idx, RES_RESERVATION_USAGE); + cft->read_u64 = hugetlb_cgroup_read_u64; + /* Add the MAX usage file */ - cft = &h->cgroup_files_legacy[2]; + cft = &h->cgroup_files_legacy[4]; snprintf(cft->name, MAX_CFTYPE_NAME, "%s.max_usage_in_bytes", buf); cft->private = MEMFILE_PRIVATE(idx, RES_MAX_USAGE); cft->write = hugetlb_cgroup_reset; cft->read_u64 = hugetlb_cgroup_read_u64; + /* Add the MAX reservation usage file */ + cft = &h->cgroup_files_legacy[5]; + snprintf(cft->name, MAX_CFTYPE_NAME, + "%s.reservation_max_usage_in_bytes", buf); + cft->private = MEMFILE_PRIVATE(idx, RES_RESERVATION_MAX_USAGE); + cft->write = hugetlb_cgroup_reset; + cft->read_u64 = hugetlb_cgroup_read_u64; + /* Add the failcntfile */ - cft = &h->cgroup_files_legacy[3]; + cft = &h->cgroup_files_legacy[6]; snprintf(cft->name, MAX_CFTYPE_NAME, "%s.failcnt", buf); - cft->private = MEMFILE_PRIVATE(idx, RES_FAILCNT); + cft->private = MEMFILE_PRIVATE(idx, RES_FAILCNT); + cft->write = hugetlb_cgroup_reset; + cft->read_u64 = hugetlb_cgroup_read_u64; + + /* Add the reservation failcntfile */ + cft = &h->cgroup_files_legacy[7]; + snprintf(cft->name, MAX_CFTYPE_NAME, "%s.reservation_failcnt", buf); + cft->private = MEMFILE_PRIVATE(idx, RES_RESERVATION_FAILCNT); cft->write = hugetlb_cgroup_reset; cft->read_u64 = hugetlb_cgroup_read_u64; /* NULL terminate the last cft */ - cft = &h->cgroup_files_legacy[4]; + cft = &h->cgroup_files_legacy[8]; memset(cft, 0, sizeof(*cft)); WARN_ON(cgroup_add_legacy_cftypes(&hugetlb_cgrp_subsys, -- 2.24.1.735.g03f4e72817-goog

4 years, 3 months

4
26
0 0

[PATCH][next] selftests: fix spelling mistake "chainged" -> "chained"

by Colin King

From: Colin Ian King <colin.king(a)canonical.com> There is a spelling mistake in a literal string, fix it. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- tools/testing/selftests/openat2/resolve_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/openat2/resolve_test.c b/tools/testing/selftests/openat2/resolve_test.c index 7a94b1da8e7b..bbafad440893 100644 --- a/tools/testing/selftests/openat2/resolve_test.c +++ b/tools/testing/selftests/openat2/resolve_test.c @@ -230,7 +230,7 @@ void test_openat2_opath_tests(void) { .name = "[in_root] garbage link to /root", .path = "cheeky/garbageself", .how.resolve = RESOLVE_IN_ROOT, .out.path = "root", .pass = true }, - { .name = "[in_root] chainged garbage links to /root", + { .name = "[in_root] chained garbage links to /root", .path = "abscheeky/garbageself", .how.resolve = RESOLVE_IN_ROOT, .out.path = "root", .pass = true }, { .name = "[in_root] relative path to 'root'", -- 2.24.0

4 years, 3 months

3
2
0 0

[PATCH v5 0/2] mm/hmm/test: add self tests for HMM

by Ralph Campbell

This series adds basic self tests for HMM and mmu interval notifiers so that changes can be validated. It is based on linux-5.5.0-rc1 and is for Jason's rdma/hmm tree since I believe he is planning some interval notifier changes. Patch 2 was last posted as part of [1] but the other patches in that series have been merged and this version of the HMM tests is modified to address Jason's concern over using both process wide MMU notifiers in combination with MMU interval notifiers. Therefore, patch 1 adds some core functionality to allow intervals to be updated from within the invalidation() callback so that MMU_NOTIFY_UNMAP events can update the range being tracked. [1] https://lore.kernel.org/linux-mm/20191104222141.5173-1-rcampbell@nvidia.com Ralph Campbell (2): mm/mmu_notifier: make interval notifier updates safe mm/hmm/test: add self tests for HMM MAINTAINERS | 3 + include/linux/mmu_notifier.h | 15 + lib/Kconfig.debug | 11 + lib/Makefile | 1 + lib/test_hmm.c | 1367 ++++++++++++++++++++++++ mm/mmu_notifier.c | 196 +++- tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 3 + tools/testing/selftests/vm/config | 2 + tools/testing/selftests/vm/hmm-tests.c | 1360 +++++++++++++++++++++++ tools/testing/selftests/vm/run_vmtests | 16 + tools/testing/selftests/vm/test_hmm.sh | 97 ++ 12 files changed, 3047 insertions(+), 25 deletions(-) create mode 100644 lib/test_hmm.c create mode 100644 tools/testing/selftests/vm/hmm-tests.c create mode 100755 tools/testing/selftests/vm/test_hmm.sh -- 2.20.1

4 years, 3 months

3
11
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror December 2019