This series first generalizes resctrl selftest non-contiguous CAT check
to not assume non-AMD vendor implies Intel. Second, it improves
kselftest common parts and resctrl selftest such that the use of
__cpuid_count() does not lead into a build failure (happens at least on
ARM).
While ARM does not currently support resctrl features, there's an
ongoing work to enable resctrl support also for it on the kernel side.
In any case, a common header such as kselftest.h should have a proper
fallback in place for what it provides, thus it seems justified to fix
this common level problem on the common level rather than e.g.
disabling build for resctrl selftest for archs lacking resctrl support.
v2:
- Removed RFC from the last patch & added Fixes and tags
- Fixed the error message's line splits
- Noted down the reason for void casts in the stub
Ilpo Järvinen (3):
selftests/resctrl: Generalize non-contiguous CAT check
selftests/resctrl: Always initialize ecx to avoid build warnings
kselftest: Provide __cpuid_count() stub on non-x86 archs
tools/testing/selftests/kselftest.h | 6 +++++
tools/testing/selftests/lib.mk | 4 ++++
tools/testing/selftests/resctrl/cat_test.c | 28 +++++++++++++---------
3 files changed, 27 insertions(+), 11 deletions(-)
--
2.39.2
Currently, running the charge_reserved_hugetlb.sh selftest we can
sometimes observe something like:
$ ./charge_reserved_hugetlb.sh -cgroup-v2
...
write_result is 0
After write:
hugetlb_usage=0
reserved_usage=10485760
killing write_to_hugetlbfs
Received 2.
Deleting the memory
Detach failure: Invalid argument
umount: /mnt/huge: target is busy.
Both cases are issues in the test.
While the unmount error seems to be racy, it will make the test fail:
$ ./run_vmtests.sh -t hugetlb
...
# [FAIL]
not ok 10 charge_reserved_hugetlb.sh -cgroup-v2 # exit=32
The issue is that we are not waiting for the write_to_hugetlbfs process
to quit. So it might still have a hugetlbfs file open, about which
umount is not happy. Fix that by making "killall" wait for the process
to quit.
The other error ("Detach failure: Invalid argument") does not seem to
result in a test error, but is misleading. Turns out write_to_hugetlbfs.c
unconditionally tries to cleanup using shmdt(), even when we only
mmap()'ed a hugetlb file. Even worse, shmaddr is never even set for the
SHM case. Fix that as well.
With this change it seems to work as expected.
Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests")
Reported-by: Mario Casquero <mcasquer(a)redhat.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Muchun Song <muchun.song(a)linux.dev>
Cc: Mina Almasry <almasrymina(a)google.com>
Signed-off-by: David Hildenbrand <david(a)redhat.com>
---
.../selftests/mm/charge_reserved_hugetlb.sh | 2 +-
.../testing/selftests/mm/write_to_hugetlbfs.c | 21 +++++++++++--------
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
index d680c00d2853a..67df7b47087f0 100755
--- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
+++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
@@ -254,7 +254,7 @@ function cleanup_hugetlb_memory() {
local cgroup="$1"
if [[ "$(pgrep -f write_to_hugetlbfs)" != "" ]]; then
echo killing write_to_hugetlbfs
- killall -2 write_to_hugetlbfs
+ killall -2 --wait write_to_hugetlbfs
wait_for_hugetlb_memory_to_get_depleted $cgroup
fi
set -e
diff --git a/tools/testing/selftests/mm/write_to_hugetlbfs.c b/tools/testing/selftests/mm/write_to_hugetlbfs.c
index 6a2caba19ee1d..1289d311efd70 100644
--- a/tools/testing/selftests/mm/write_to_hugetlbfs.c
+++ b/tools/testing/selftests/mm/write_to_hugetlbfs.c
@@ -28,7 +28,7 @@ enum method {
/* Global variables. */
static const char *self;
-static char *shmaddr;
+static int *shmaddr;
static int shmid;
/*
@@ -47,15 +47,17 @@ void sig_handler(int signo)
{
printf("Received %d.\n", signo);
if (signo == SIGINT) {
- printf("Deleting the memory\n");
- if (shmdt((const void *)shmaddr) != 0) {
- perror("Detach failure");
+ if (shmaddr) {
+ printf("Deleting the memory\n");
+ if (shmdt((const void *)shmaddr) != 0) {
+ perror("Detach failure");
+ shmctl(shmid, IPC_RMID, NULL);
+ exit(4);
+ }
+
shmctl(shmid, IPC_RMID, NULL);
- exit(4);
+ printf("Done deleting the memory\n");
}
-
- shmctl(shmid, IPC_RMID, NULL);
- printf("Done deleting the memory\n");
}
exit(2);
}
@@ -211,7 +213,8 @@ int main(int argc, char **argv)
shmctl(shmid, IPC_RMID, NULL);
exit(2);
}
- printf("shmaddr: %p\n", ptr);
+ shmaddr = ptr;
+ printf("shmaddr: %p\n", shmaddr);
break;
default:
--
2.46.0
From: Steven Rostedt <rostedt(a)goodmis.org>
Masami reported a bug when running function graph tracing then the
function profiler. The following commands would cause a kernel crash:
# cd /sys/kernel/tracing/
# echo function_graph > current_tracer
# echo 1 > function_profile_enabled
In that order. Create a test to test this two to make sure this does not
come back as a regression.
Link: https://lore.kernel.org/172398528350.293426.8347220120333730248.stgit@devno…
Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
---
.../ftrace/test.d/ftrace/fgraph-profiler.tc | 30 +++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 tools/testing/selftests/ftrace/test.d/ftrace/fgraph-profiler.tc
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-profiler.tc b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-profiler.tc
new file mode 100644
index 000000000000..62d44a1395da
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-profiler.tc
@@ -0,0 +1,30 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: ftrace - function profiler with function graph tracing
+# requires: function_profile_enabled set_ftrace_filter function_graph:tracer
+
+# The function graph tracer can now be run along side of the function
+# profiler. But there was a bug that caused the combination of the two
+# to crash. It also required the function graph tracer to be started
+# first.
+#
+# This test triggers that bug
+#
+# We need function_graph and profiling to to run this test
+
+fail() { # mesg
+ echo $1
+ exit_fail
+}
+
+echo "Enabling function graph tracer:"
+echo function_graph > current_tracer
+echo "enable profiler"
+
+# Older kernels do not allow function_profile to be enabled with
+# function graph tracer. If the below fails, mark it as unsupported
+echo 1 > function_profile_enabled || exit_unsupported
+
+sleep 1
+
+exit 0
--
2.43.0
On some machines with a large number of CPUs there is a sizable delay
between an atomic replace occurring and when sysfs updates accordingly.
This fix uses 'loop_until' to wait for the atomic replace to unload all
previous livepatches.
Signed-off-by: Ryan Sullivan <rysulliv(a)redhat.com>
---
tools/testing/selftests/livepatch/test-livepatch.sh | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/livepatch/test-livepatch.sh b/tools/testing/selftests/livepatch/test-livepatch.sh
index 65c9c058458d..bd13257bfdfe 100755
--- a/tools/testing/selftests/livepatch/test-livepatch.sh
+++ b/tools/testing/selftests/livepatch/test-livepatch.sh
@@ -139,11 +139,8 @@ load_lp $MOD_REPLACE replace=1
grep 'live patched' /proc/cmdline > /dev/kmsg
grep 'live patched' /proc/meminfo > /dev/kmsg
-mods=(/sys/kernel/livepatch/*)
-nmods=${#mods[@]}
-if [ "$nmods" -ne 1 ]; then
- die "Expecting only one moduled listed, found $nmods"
-fi
+loop_until 'mods=(/sys/kernel/livepatch/*); nmods=${#mods[@]}; [[ "$nmods" -eq 1 ]]' ||
+ die "Expecting only one moduled listed, found $nmods"
# These modules were disabled by the atomic replace
for mod in $MOD_LIVEPATCH3 $MOD_LIVEPATCH2 $MOD_LIVEPATCH1; do
--
2.44.0
I noticed some bugs here while working on iommupt. Fix them up.
Joerg, can you pick this both for your -rc branch?
Thanks,
Jason
Jason Gunthorpe (2):
iommufd: Do not allow creating areas without READ or WRITE
iommu: Do not return 0 from map_pages if it doesn't do anything
drivers/iommu/io-pgtable-arm-v7s.c | 3 +--
drivers/iommu/io-pgtable-arm.c | 3 +--
drivers/iommu/io-pgtable-dart.c | 3 +--
drivers/iommu/iommufd/ioas.c | 8 ++++++++
tools/testing/selftests/iommu/iommufd.c | 6 +++---
5 files changed, 14 insertions(+), 9 deletions(-)
base-commit: 4be8b00b2b0f669989486e9f2fb9b65edb4ef8c4
--
2.46.0
Hi guys,
This is another try to allow userspace to change ID_AA64PFR1_EL1, and we want to
give userspace the ability to control the visible feature set for a VM, which
could be used by userspace in such a way to transparently migrate VMs.
The patch series have four part:
The first patch disable those fields which KVM doesn't know how to handle, so
KVM will only expose value 0 of those fields to the guest.
The second patch check the FEAT_SSBS in guest IDREG instead of the cpu
capability.
The third patch allow userspace to change ID_AA64PFR1_EL1, it only advertise the
fields known to KVM and leave others unadvertise.
The fourth patch adds the kselftest to test if userspace can change the
ID_AA64PFR1_EL1.
Besides, I also noticed there is another patch [1] which try to make the
ID_AA64PFR1_EL1 writable. This patch [1] is try to enable GCS on baremental, and
add GCS support for the guest. What I understand is if we have GCS support on
baremental, it will be clear to how to handle them in KVM. And same for other
fields like NMI, THE, DF2, MTEX.. At that time, they can be writable.
[1] [PATCH v9 13/39] KVM: arm64: Manage GCS registers for guests
https://lore.kernel.org/all/20240625-arm64-gcs-v9-13-0f634469b8f0@kernel.or…
Changelog:
----------
v4 -> v5:
* Only advertise fields which KVM know how to handle to userspace, leave
others unadvertised.
* Add a new patch to check FEAT_SSBS in IDREG instead of cpu capability.
* Tweak the kselftest writable fields.
* Improve the commit message.
v3 -> v4:
* Add a new patch to disable some feature which KVM doesn't know how to
handle in the register accessor.
* Handle all the fields in the register.
* Fixes a small cnt issue in kselftest.
v2 -> v3:
* Give more description about why only part of the fields can be writable.
* Updated the writable mask by referring the latest ARM spec.
v1 -> v2:
* Tackling the full register instead of single field.
* Changing the patch title and commit message.
RFCv1 -> v1:
* Fix the compilation error.
* Delete the machine specific information and make the description more
generable.
RFCv1: https://lore.kernel.org/all/20240612023553.127813-1-shahuang@redhat.com/
v1: https://lore.kernel.org/all/20240617075131.1006173-1-shahuang@redhat.com/
v2: https://lore.kernel.org/all/20240618063808.1040085-1-shahuang@redhat.com/
v3: https://lore.kernel.org/all/20240628060454.1936886-2-shahuang@redhat.com/
v4: https://lore.kernel.org/all/20240718035017.434996-1-shahuang@redhat.com/
Shaoqin Huang (4):
KVM: arm64: Disable fields that KVM doesn't know how to handle in
ID_AA64PFR1_EL1
KVM: arm64: Use kvm_has_feat() to check if FEAT_SSBS is advertised to
the guest
KVM: arm64: Allow userspace to change ID_AA64PFR1_EL1
KVM: selftests: aarch64: Add writable test for ID_AA64PFR1_EL1
arch/arm64/kvm/hypercalls.c | 12 +++++-----
arch/arm64/kvm/sys_regs.c | 22 ++++++++++++++++++-
.../selftests/kvm/aarch64/set_id_regs.c | 14 +++++++++---
3 files changed, 38 insertions(+), 10 deletions(-)
--
2.40.1
If a BPF selftest program requires (recent) UAPI headers [1], it is
currently needed to duplicate these header files into tools/include/uapi.
That's not a good solution, because it is a duplication that needs to be
kept up-to-date, while the required files are only a few directories
away.
A solution to avoid these duplicated files is to use the KHDR_INCLUDES
from the kselftest infrastructure. That is what is being done in the
first patch.
The second patch removes 'if_xdp.h', which is no longer needed, and was
causing a warning when building the libbpf required by the BPF
selftests. There could be more duplicated UAPI header files that could
be removed, but I didn't spend too much time checking which ones are not
used by anything else from the 'tools' directory.
Hopefully, these modifications should not cause any issues on the
different CIs, because it is using the recommended method for the kernel
selftests. If this causes issues on the CIs side, it should be easy to
fix by overriding the KHDR_INCLUDES variable, and it might be better to
do that, because it likely means the CI is not following the recommended
way to execute the kernel selftests. See patch 1/2 for more details
about that.
Link: https://lore.kernel.org/all/08f925cd-e267-4a6b-84b1-792515c4e199@kernel.org… [1]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
---
Matthieu Baerts (NGI0) (2):
selftests: bpf: use KHDR_INCLUDES for the UAPI headers
selftests: bpf: remove duplicated UAPI if_xdp headers
tools/include/uapi/linux/if_xdp.h | 173 ---------------------
tools/lib/bpf/Makefile | 3 -
tools/testing/selftests/bpf/Makefile | 2 +-
.../selftests/bpf/prog_tests/assign_reuse.c | 2 +-
tools/testing/selftests/bpf/prog_tests/tc_links.c | 4 +-
tools/testing/selftests/bpf/prog_tests/tc_netkit.c | 2 +-
tools/testing/selftests/bpf/prog_tests/tc_opts.c | 2 +-
.../selftests/bpf/prog_tests/user_ringbuf.c | 2 +-
.../testing/selftests/bpf/prog_tests/xdp_bonding.c | 2 +-
.../selftests/bpf/prog_tests/xdp_cpumap_attach.c | 2 +-
.../selftests/bpf/prog_tests/xdp_devmap_attach.c | 2 +-
.../selftests/bpf/prog_tests/xdp_do_redirect.c | 2 +-
tools/testing/selftests/bpf/prog_tests/xdp_link.c | 2 +-
tools/testing/selftests/bpf/xdp_features.c | 4 +-
14 files changed, 14 insertions(+), 190 deletions(-)
---
base-commit: fdf1c728fac541891ef1aa773bfd42728626769c
change-id: 20240816-ups-bpf-next-selftests-use-khdr-28f935c8848a
Best regards,
--
Matthieu Baerts (NGI0) <matttbe(a)kernel.org>