August 2024 - Linux-kselftest-mirror

[PATCH] Improve timer_create failure message

by Gianfranco Trad

Improve timer_create failure message to give more information to the user. Signed-off-by: Gianfranco Trad <gianf.trad(a)gmail.com> --- tools/testing/selftests/timers/alarmtimer-suspend.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/timers/alarmtimer-suspend.c b/tools/testing/selftests/timers/alarmtimer-suspend.c index ad52e608b88e..74acdb87d4f4 100644 --- a/tools/testing/selftests/timers/alarmtimer-suspend.c +++ b/tools/testing/selftests/timers/alarmtimer-suspend.c @@ -28,6 +28,7 @@ #include <signal.h> #include <stdlib.h> #include <pthread.h> +#include <errno.h> #include "../kselftest.h" #define CLOCK_REALTIME 0 @@ -142,8 +143,8 @@ int main(void) alarmcount = 0; if (timer_create(alarm_clock_id, &se, &tm1) == -1) { - printf("timer_create failed, %s unsupported?\n", - clockstring(alarm_clock_id)); + printf("timer_create failed, %s unsupported?: %s\n", + clockstring(alarm_clock_id), strerror(errno)); break; } -- 2.43.0

1 week, 4 days

4
5
0 0

[PATCH v2 00/25] Enable FRED with KVM VMX

by Xin Li

This patch set enables the Intel flexible return and event delivery (FRED) architecture with KVM VMX to allow guests to utilize FRED. The FRED architecture defines simple new transitions that change privilege level (ring transitions). The FRED architecture was designed with the following goals: 1) Improve overall performance and response time by replacing event delivery through the interrupt descriptor table (IDT event delivery) and event return by the IRET instruction with lower latency transitions. 2) Improve software robustness by ensuring that event delivery establishes the full supervisor context and that event return establishes the full user context. The new transitions defined by the FRED architecture are FRED event delivery and, for returning from events, two FRED return instructions. FRED event delivery can effect a transition from ring 3 to ring 0, but it is used also to deliver events incident to ring 0. One FRED instruction (ERETU) effects a return from ring 0 to ring 3, while the other (ERETS) returns while remaining in ring 0. Collectively, FRED event delivery and the FRED return instructions are FRED transitions. Intel VMX architecture is extended to run FRED guests, and the major changes are: 1) New VMCS fields for FRED context management, which includes two new event data VMCS fields, eight new guest FRED context VMCS fields and eight new host FRED context VMCS fields. 2) VMX nested-exception support for proper virtualization of stack levels introduced with FRED architecture. Search for the latest FRED spec in most search engines with this search pattern: site:intel.com FRED (flexible return and event delivery) specification As the native FRED patches are committed in the tip tree "x86/fred" branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/fred, and we have received a good amount of review comments for v1, it's time to send out v2 based on this branch for further help from the community. Patch 1-2 are cleanups to VMX basic and misc MSRs, which were sent out earlier as a preparation for FRED changes: https://lore.kernel.org/kvm/20240206182032.1596-1-xin3.li@intel.com/T/#u Patch 3-15 add FRED support to VMX. Patch 16-21 add FRED support to nested VMX. Patch 22 exposes FRED and its baseline features to KVM guests. Patch 23-25 add FRED selftests. There is also a counterpart qemu patch set for FRED at: https://lore.kernel.org/qemu-devel/20231109072012.8078-1-xin3.li@intel.com/…, which works with this patch set to allow KVM to run FRED guests. Changes since v1: * Always load the secondary VM exit controls (Sean Christopherson). * Remove FRED VM entry/exit controls consistency checks in setup_vmcs_config() (Sean Christopherson). * Clear FRED VM entry/exit controls if FRED is not enumerated (Chao Gao). * Use guest_can_use() to trace FRED enumeration in a vcpu (Chao Gao). * Enable FRED MSRs intercept if FRED is no longer enumerated in CPUID (Chao Gao). * Move guest FRED states init into __vmx_vcpu_reset() (Chao Gao). * Don't use guest_cpuid_has() in vmx_prepare_switch_to_{host,guest}(), which are called from IRQ-disabled context (Chao Gao). * Reset msr_guest_fred_rsp0 in __vmx_vcpu_reset() (Chao Gao). * Fail host requested FRED MSRs access if KVM cannot virtualize FRED (Chao Gao). * Handle the case FRED MSRs are valid but KVM cannot virtualize FRED (Chao Gao). * Add sanity checks when writing to FRED MSRs. * Explain why it is ok to only check CR4.FRED in kvm_is_fred_enabled() (Chao Gao). * Document event data should be equal to CR2/DR6/IA32_XFD_ERR instead of using WARN_ON() (Chao Gao). * Zero event data if a #NM was not caused by extended feature disable (Chao Gao). * Set the nested flag when there is an original interrupt (Chao Gao). * Dump guest FRED states only if guest has FRED enabled (Nikolay Borisov). * Add a prerequisite to SHADOW_FIELD_R[OW] macros * Remove hyperv TLFS related changes (Jeremi Piotrowski). * Use kvm_cpu_cap_has() instead of cpu_feature_enabled() to decouple KVM's capability to virtualize a feature and host's enabling of a feature (Chao Gao). Xin Li (25): KVM: VMX: Cleanup VMX basic information defines and usages KVM: VMX: Cleanup VMX misc information defines and usages KVM: VMX: Add support for the secondary VM exit controls KVM: x86: Mark CR4.FRED as not reserved KVM: VMX: Initialize FRED VM entry/exit controls in vmcs_config KVM: VMX: Defer enabling FRED MSRs save/load until after set CPUID KVM: VMX: Set intercept for FRED MSRs KVM: VMX: Initialize VMCS FRED fields KVM: VMX: Switch FRED RSP0 between host and guest KVM: VMX: Add support for FRED context save/restore KVM: x86: Add kvm_is_fred_enabled() KVM: VMX: Handle FRED event data KVM: VMX: Handle VMX nested exception for FRED KVM: VMX: Disable FRED if FRED consistency checks fail KVM: VMX: Dump FRED context in dump_vmcs() KVM: VMX: Invoke vmx_set_cpu_caps() before nested setup KVM: nVMX: Add support for the secondary VM exit controls KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros KVM: nVMX: Add FRED VMCS fields KVM: nVMX: Add support for VMX FRED controls KVM: nVMX: Add VMCS FRED states checking KVM: x86: Allow FRED/LKGS/WRMSRNS to be exposed to guests KVM: selftests: Run debug_regs test with FRED enabled KVM: selftests: Add a new VM guest mode to run user level code KVM: selftests: Add fred exception tests Documentation/virt/kvm/x86/nested-vmx.rst | 19 + arch/x86/include/asm/kvm_host.h | 8 +- arch/x86/include/asm/msr-index.h | 15 +- arch/x86/include/asm/vmx.h | 59 ++- arch/x86/kvm/cpuid.c | 4 +- arch/x86/kvm/governed_features.h | 1 + arch/x86/kvm/kvm_cache_regs.h | 17 + arch/x86/kvm/svm/svm.c | 4 +- arch/x86/kvm/vmx/capabilities.h | 30 +- arch/x86/kvm/vmx/nested.c | 329 ++++++++++++--- arch/x86/kvm/vmx/nested.h | 2 +- arch/x86/kvm/vmx/vmcs.h | 1 + arch/x86/kvm/vmx/vmcs12.c | 19 + arch/x86/kvm/vmx/vmcs12.h | 38 ++ arch/x86/kvm/vmx/vmcs_shadow_fields.h | 80 ++-- arch/x86/kvm/vmx/vmx.c | 385 +++++++++++++++--- arch/x86/kvm/vmx/vmx.h | 15 +- arch/x86/kvm/x86.c | 103 ++++- arch/x86/kvm/x86.h | 5 +- tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/include/kvm_util_base.h | 1 + .../selftests/kvm/include/x86_64/processor.h | 36 ++ tools/testing/selftests/kvm/lib/kvm_util.c | 5 +- .../selftests/kvm/lib/x86_64/processor.c | 15 +- tools/testing/selftests/kvm/lib/x86_64/vmx.c | 4 +- .../testing/selftests/kvm/x86_64/debug_regs.c | 50 ++- .../testing/selftests/kvm/x86_64/fred_test.c | 297 ++++++++++++++ 27 files changed, 1320 insertions(+), 223 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/fred_test.c base-commit: e13841907b8fda0ae0ce1ec03684665f578416a8 -- 2.43.0

1 week, 4 days

8
93
0 0

[PATCH v4] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING`

by Barnabás Pőcze

`MFD_NOEXEC_SEAL` should remove the executable bits and set `F_SEAL_EXEC` to prevent further modifications to the executable bits as per the comment in the uapi header file: not executable and sealed to prevent changing to executable However, commit 105ff5339f498a ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC") that introduced this feature made it so that `MFD_NOEXEC_SEAL` unsets `F_SEAL_SEAL`, essentially acting as a superset of `MFD_ALLOW_SEALING`. Nothing implies that it should be so, and indeed up until the second version of the of the patchset[0] that introduced `MFD_EXEC` and `MFD_NOEXEC_SEAL`, `F_SEAL_SEAL` was not removed, however, it was changed in the third revision of the patchset[1] without a clear explanation. This behaviour is surprising for application developers, there is no documentation that would reveal that `MFD_NOEXEC_SEAL` has the additional effect of `MFD_ALLOW_SEALING`. Additionally, combined with `vm.memfd_noexec=2` it has the effect of making all memfds initially sealable. So do not remove `F_SEAL_SEAL` when `MFD_NOEXEC_SEAL` is requested, thereby returning to the pre-Linux 6.3 behaviour of only allowing sealing when `MFD_ALLOW_SEALING` is specified. Now, this is technically a uapi break. However, the damage is expected to be minimal. To trigger user visible change, a program has to do the following steps: - create memfd: - with `MFD_NOEXEC_SEAL`, - without `MFD_ALLOW_SEALING`; - try to add seals / check the seals. But that seems unlikely to happen intentionally since this change essentially reverts the kernel's behaviour to that of Linux <6.3, so if a program worked correctly on those older kernels, it will likely work correctly after this change. I have used Debian Code Search and GitHub to try to find potential breakages, and I could only find a single one. dbus-broker's memfd_create() wrapper is aware of this implicit `MFD_ALLOW_SEALING` behaviour, and tries to work around it[2]. This workaround will break. Luckily, this only affects the test suite, it does not affect the normal operations of dbus-broker. There is a PR with a fix[3]. I also carried out a smoke test by building a kernel with this change and booting an Arch Linux system into GNOME and Plasma sessions. There was also a previous attempt to address this peculiarity by introducing a new flag[4]. [0]: https://lore.kernel.org/lkml/20220805222126.142525-3-jeffxu@google.com/ [1]: https://lore.kernel.org/lkml/20221202013404.163143-3-jeffxu@google.com/ [2]: https://github.com/bus1/dbus-broker/blob/9eb0b7e5826fc76cad7b025bc46f267d4a… [3]: https://github.com/bus1/dbus-broker/pull/366 [4]: https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/ Cc: stable(a)vger.kernel.org Signed-off-by: Barnabás Pőcze <pobrn(a)protonmail.com> --- * v3: https://lore.kernel.org/linux-mm/20240611231409.3899809-1-jeffxu@chromium.o… * v2: https://lore.kernel.org/linux-mm/20240524033933.135049-1-jeffxu@google.com/ * v1: https://lore.kernel.org/linux-mm/20240513191544.94754-1-pobrn@protonmail.co… This fourth version returns to removing the inconsistency as opposed to documenting its existence, with the same code change as v1 but with a somewhat extended commit message. This is sent because I believe it is worth at least a try; it can be easily reverted if bigger application breakages are discovered than initially imagined. --- mm/memfd.c | 9 ++++----- tools/testing/selftests/memfd/memfd_test.c | 2 +- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/mm/memfd.c b/mm/memfd.c index 7d8d3ab3fa37..8b7f6afee21d 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -356,12 +356,11 @@ SYSCALL_DEFINE2(memfd_create, inode->i_mode &= ~0111; file_seals = memfd_file_seals_ptr(file); - if (file_seals) { - *file_seals &= ~F_SEAL_SEAL; + if (file_seals) *file_seals |= F_SEAL_EXEC; - } - } else if (flags & MFD_ALLOW_SEALING) { - /* MFD_EXEC and MFD_ALLOW_SEALING are set */ + } + + if (flags & MFD_ALLOW_SEALING) { file_seals = memfd_file_seals_ptr(file); if (file_seals) *file_seals &= ~F_SEAL_SEAL; diff --git a/tools/testing/selftests/memfd/memfd_test.c b/tools/testing/selftests/memfd/memfd_test.c index 95af2d78fd31..7b78329f65b6 100644 --- a/tools/testing/selftests/memfd/memfd_test.c +++ b/tools/testing/selftests/memfd/memfd_test.c @@ -1151,7 +1151,7 @@ static void test_noexec_seal(void) mfd_def_size, MFD_CLOEXEC | MFD_NOEXEC_SEAL); mfd_assert_mode(fd, 0666); - mfd_assert_has_seals(fd, F_SEAL_EXEC); + mfd_assert_has_seals(fd, F_SEAL_SEAL | F_SEAL_EXEC); mfd_fail_chmod(fd, 0777); close(fd); } -- 2.45.2

2 weeks

3
3
0 0

[PATCH 0/2] selftest: rtc: Add rtc feature detection and rtc file check

by Joseph Jang

1. In order to make rtctest more explicit and robust, we propose to use RTC_PARAM_GET ioctl interface to check rtc alarm feature state before running alarm related tests. 2. The rtctest requires the read permission on /dev/rtc0. The rtctest will be skipped if the /dev/rtc0 is not readable. Joseph Jang (2): selftest: rtc: Add to check rtc alarm status for alarm related test selftest: rtc: Check if could access /dev/rtc0 before testing tools/testing/selftests/rtc/Makefile | 2 +- tools/testing/selftests/rtc/rtctest.c | 71 ++++++++++++++++++++++++++- 2 files changed, 71 insertions(+), 2 deletions(-) -- 2.34.1

2 weeks, 3 days

3
10
0 0

[PATCH v3 0/5] KVM: s390: selftests: Add regression tests for CPU subfunctions

by Hariharan Mari

This patch series introduces a set of regression tests for various s390x CPU subfunctions in KVM. The tests ensure that the KVM implementation accurately reflects the behavior of actual CPU instructions for these subfunctions. The series adds tests for a total of 15 instructions across five patches, covering a range of operations including sorting, compression, and various cryptographic functions. Each patch follows a consistent testing pattern: 1. Obtain the KVM_S390_VM_CPU_MACHINE_SUBFUNC attribute for the VM. 2. Execute the relevant asm instructions. 3. Compare KVM-reported results with direct instruction execution results. Testing has been performed on s390x hardware with KVM support. All tests pass successfully, verifying the correct implementation of these subfunctions in KVM. --- v2: * Fix facility_bit type from bool to int v3: * Global variable in the header is moved to facility.c file in selftests/kvm/lib/s390x/ * Fixed the line length * Fixed single line comments and multiline comments * Renamed the PLO macro * Removed the unnecessary type cast where Implicit type promotion applies --- Hariharan Mari (5): KVM: s390: selftests: Add regression tests for SORTL and DFLTCC CPU subfunctions KVM: s390: selftests: Add regression tests for PRNO, KDSA and KMA crypto subfunctions KVM: s390: selftests: Add regression tests for KMCTR, KMF, KMO and PCC crypto subfunctions KVM: s390: selftests: Add regression tests for KMAC, KMC, KM, KIMD and KLMD crypto subfunctions KVM: s390: selftests: Add regression tests for PLO subfunctions tools/testing/selftests/kvm/Makefile | 2 + .../selftests/kvm/include/s390x/facility.h | 50 +++ .../selftests/kvm/lib/s390x/facility.c | 14 + .../kvm/s390x/cpumodel_subfuncs_test.c | 286 ++++++++++++++++++ 4 files changed, 352 insertions(+) create mode 100644 tools/testing/selftests/kvm/include/s390x/facility.h create mode 100644 tools/testing/selftests/kvm/lib/s390x/facility.c create mode 100644 tools/testing/selftests/kvm/s390x/cpumodel_subfuncs_test.c -- 2.45.2

2 weeks, 3 days

3
8
0 0

[PATCH v3 0/5] Increase mseal test coverage

by jeffxu＠chromium.org

From: Jeff Xu <jeffxu(a)chromium.org> This series increase the test coverage of mseal_test by: Add check for vma_size, prot, and error code for existing tests. Add more testcases for madvise, munmap, mmap and mremap to cover sealing in different scenarios. The increase test coverage hopefully help to prevent future regression. It doesn't change any existing mm api's semantics, i.e. it will pass on linux main and 6.10 branch. Note: in order to pass this test in mm-unstable, mm-unstable must have Liam's fix on mmap [1] [1] https://lore.kernel.org/linux-kselftest/vyllxuh5xbqmaoyl2mselebij5ox7cseekj… History: V3: - no-functional change, incooperate feedback from Pedro Falcato V2: - https://lore.kernel.org/linux-kselftest/20240829214352.963001-1-jeffxu@chro… - remove the mmap fix (Liam R. Howlett will fix it separately) - Add cover letter (Lorenzo Stoakes) - split the testcase for ease of review (Mark Brown) V1: - https://lore.kernel.org/linux-kselftest/20240828225522.684774-1-jeffxu@chro… Jeff Xu (5): selftests/mseal_test: Check vma_size, prot, error code. selftests/mseal: add sealed madvise type selftests/mseal: munmap across multiple vma ranges. selftests/mseal: add more tests for mmap selftests/mseal: add more tests for mremap tools/testing/selftests/mm/mseal_test.c | 830 ++++++++++++++++++++++-- 1 file changed, 763 insertions(+), 67 deletions(-) -- 2.46.0.469.g59c65b2a67-goog

3 weeks

5
17
0 0

[RFC PATCH v1 0/4] Add support for the Bus Lock Threshold

by Manali Shukla

Malicious guests can cause bus locks to degrade the performance of a system. Non-WB (write-back) and misaligned locked RMW (read-modify-write) instructions are referred to as "bus locks" and require system wide synchronization among all processors to guarantee the atomicity. The bus locks can impose notable performance penalties for all processors within the system. Support for the Bus Lock Threshold is indicated by CPUID Fn8000_000A_EDX[29] BusLockThreshold=1, the VMCB provides a Bus Lock Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. VMCB intercept bit VMCB Offset Bits Function 14h 5 Intercept bus lock operations Bus lock threshold count VMCB Offset Bits Function 120h 15:0 Bus lock counter During VMRUN, the bus lock threshold count is fetched and stored in an internal count register. Prior to executing a bus lock within the guest, the processor verifies the count in the bus lock register. If the count is greater than zero, the processor executes the bus lock, reducing the count. However, if the count is zero, the bus lock operation is not performed, and instead, a Bus Lock Threshold #VMEXIT is triggered to transfer control to the Virtual Machine Monitor (VMM). A Bus Lock Threshold #VMEXIT is reported to the VMM with VMEXIT code 0xA5h, VMEXIT_BUSLOCK. EXITINFO1 and EXITINFO2 are set to 0 on a VMEXIT_BUSLOCK. On a #VMEXIT, the processor writes the current value of the Bus Lock Threshold Counter to the VMCB. More details about the Bus Lock Threshold feature can be found in AMD APM [1]. Patches are prepared on kvm-x86/svm (704ec48fc2fb) Testing done: - Added a selftest for the Bus Lock Threadshold functionality. - Tested the Bus Lock Threshold functionality on SEV and SEV-ES guests. - Tested the Bus Lock Threshold functionality on nested guests. Qemu changes can be found on: Repo: https://github.com/AMDESE/qemu.git Branch: buslock_threshold Qemu commandline to use the bus lock threshold functionality: qemu-system-x86_64 -enable-kvm -cpu EPYC-Turin,+svm -M q35,bus-lock-ratelimit=10 \ .. [1]: AMD64 Architecture Programmer's Manual Pub. 24593, April 2024, Vol 2, 15.14.5 Bus Lock Threshold. https://bugzilla.kernel.org/attachment.cgi?id=306250 Manali Shukla (2): x86/cpufeatures: Add CPUID feature bit for the Bus Lock Threshold KVM: x86: nSVM: Implement support for nested Bus Lock Threshold Nikunj A Dadhania (2): KVM: SVM: Enable Bus lock threshold exit KVM: selftests: Add bus lock exit test arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/svm.h | 5 +- arch/x86/include/uapi/asm/svm.h | 2 + arch/x86/kvm/governed_features.h | 1 + arch/x86/kvm/svm/nested.c | 25 ++++ arch/x86/kvm/svm/svm.c | 48 ++++++++ arch/x86/kvm/svm/svm.h | 1 + arch/x86/kvm/x86.h | 1 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/x86_64/svm_buslock_test.c | 114 ++++++++++++++++++ 10 files changed, 198 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/kvm/x86_64/svm_buslock_test.c base-commit: 704ec48fc2fbd4e41ec982662ad5bf1eee33eeb2 -- 2.34.1

3 weeks

3
25
0 0

[PATCH v4 0/2] selftests/resctrl: SNC kernel support discovery

by Maciej Wieczor-Retman

Changes v4: - Printing SNC warnings at the start of every test. - Printing SNC warnings at the end of every relevant test. - Remove global snc_mode variable, consolidate snc detection functions into one. - Correct minor mistakes. Changes v3: - Reworked patch 2. - Changed minor things in patch 1 like function name and made corrections to the patch message. Changes v2: - Removed patches 2 and 3 since now this part will be supported by the kernel. Sub-Numa Clustering (SNC) allows splitting CPU cores, caches and memory into multiple NUMA nodes. When enabled, NUMA-aware applications can achieve better performance on bigger server platforms. SNC support in the kernel was merged into x86/cache [1]. With SNC enabled and kernel support in place all the tests will function normally (aside from effective cache size). There might be a problem when SNC is enabled but the system is still using an older kernel version without SNC support. Currently the only message displayed in that situation is a guess that SNC might be enabled and is causing issues. That message also is displayed whenever the test fails on an Intel platform. Add a mechanism to discover kernel support for SNC which will add more meaning and certainty to the error message. Add runtime SNC mode detection and verify how reliable that information is. Series was tested on Ice Lake server platforms with SNC disabled, SNC-2 and SNC-4. The tests were also ran with and without kernel support for SNC. Series applies cleanly on kselftest/next. [1] https://lore.kernel.org/all/20240628215619.76401-1-tony.luck@intel.com/ Previous versions of this series: [v1] https://lore.kernel.org/all/cover.1709721159.git.maciej.wieczor-retman@inte… [v2] https://lore.kernel.org/all/cover.1715769576.git.maciej.wieczor-retman@inte… [v3] https://lore.kernel.org/all/cover.1719842207.git.maciej.wieczor-retman@inte… Maciej Wieczor-Retman (2): selftests/resctrl: Adjust effective L3 cache size with SNC enabled selftests/resctrl: Adjust SNC support messages tools/testing/selftests/resctrl/cat_test.c | 8 ++ tools/testing/selftests/resctrl/cmt_test.c | 10 +- tools/testing/selftests/resctrl/mba_test.c | 7 + tools/testing/selftests/resctrl/mbm_test.c | 9 +- tools/testing/selftests/resctrl/resctrl.h | 7 + .../testing/selftests/resctrl/resctrl_tests.c | 8 +- tools/testing/selftests/resctrl/resctrlfs.c | 130 ++++++++++++++++++ 7 files changed, 174 insertions(+), 5 deletions(-) -- 2.45.2

3 weeks, 1 day

2
8
0 0

[PATCH] selftests: riscv: Allow mmap test to compile on 32-bit

by Charlie Jenkins

Macros needed for 32-bit compilations were hidden behind 64-bit riscv ifdefs. Fix the 32-bit compilations by moving macros to allow the memory_layout test to run on 32-bit. Signed-off-by: Charlie Jenkins <charlie(a)rivosinc.com> Fixes: 73d05262a2ca ("selftests: riscv: Generalize mm selftests") --- tools/testing/selftests/riscv/mm/mmap_test.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/riscv/mm/mmap_test.h b/tools/testing/selftests/riscv/mm/mmap_test.h index 3b29ca3bb3d4..1c3313c201d5 100644 --- a/tools/testing/selftests/riscv/mm/mmap_test.h +++ b/tools/testing/selftests/riscv/mm/mmap_test.h @@ -48,11 +48,11 @@ uint32_t random_addresses[] = { }; #endif -// Only works on 64 bit -#if __riscv_xlen == 64 #define PROT (PROT_READ | PROT_WRITE) #define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS) +// Only works on 64 bit +#if __riscv_xlen == 64 /* mmap must return a value that doesn't use more bits than the hint address. */ static inline unsigned long get_max_value(unsigned long input) { @@ -80,6 +80,8 @@ static inline unsigned long get_max_value(unsigned long input) }) #endif /* __riscv_xlen == 64 */ +#define TEST_MMAPS do { } while (0) + static inline int memory_layout(void) { void *value1 = mmap(NULL, sizeof(int), PROT, FLAGS, 0, 0); --- base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b change-id: 20240807-mmap_tests__fixes-651cc2b5fead -- - Charlie

3 weeks, 3 days

2
1
0 0

[PATCH bpf-next v4 0/8] libbpf, selftests/bpf: Support cross-endian usage

by Tony Ambardar

Hello all, This patch series targets a long-standing BPF usability issue - the lack of general cross-compilation support - by enabling cross-endian usage of libbpf and bpftool, as well as supporting cross-endian build targets for selftests/bpf. Benefits include improved BPF development and testing for embedded systems based on e.g. big-endian MIPS, more build options e.g for s390x systems, and better accessibility to the very latest test tools e.g. 'test_progs'. Initial development and testing used mips64, since this arch makes switching the build byte-order trivial and is thus very handy for A/B testing. However, it lacks some key features (bpf2bpf call, kfuncs, etc) making for poor selftests/bpf coverage. Final testing takes the kernel and selftests/bpf cross-built from x86_64 to s390x, and runs the result under QEMU/s390x. That same configuration could also be used on kernel-patches/bpf CI for regression testing endian support or perhaps load-sharing s390x builds across x86_64 systems. This thread includes some background regarding testing on QEMU/s390x and the generally favourable results: https://lore.kernel.org/bpf/ZsEcsaa3juxxQBUf@kodidev-ubuntu/ Feedback and suggestions are welcome! Best regards, Tony Changelog: --------- v3 -> v4: - fix a use-after-free ELF data-handling error causing rare CI failures - move bswap functions for func/line/core-relo records to internal header - use bswap functions also for info blobs in light skeleton v2 -> v3: (feedback from Andrii) - improve some log and commit message formatting - restructure BTF.ext endianness safety checks and byte-swapping - use BTF.ext info record definitions for swapping, require BTF v1 - follow BTF API implementation more closely for BTF.ext - explicitly reject loading non-native endianness program into kernel - simplify linker output byte-order setting - drop redundant safety checks during linking - simplify endianness macro and improve blob setup code for light skel - no unexpected test failures after cross-compiling x86_64 -> s390x v1 -> v2: - fixed a light skeleton bug causing test_progs 'map_ptr' failure - simplified some BTF.ext related endianness logic - remove an 'inline' usage related to CI checkpatch failure - improve some formatting noted by checkpatch warnings - unexpected 'test_progs' failures drop 3 -> 2 (x86_64 to s390x cross) Tony Ambardar (8): libbpf: Improve log message formatting libbpf: Fix header comment typos for BTF.ext libbpf: Fix output .symtab byte-order during linking libbpf: Support BTF.ext loading and output in either endianness libbpf: Support opening bpf objects of either endianness libbpf: Support linking bpf objects of either endianness libbpf: Support creating light skeleton of either endianness selftests/bpf: Support cross-endian building tools/lib/bpf/bpf_gen_internal.h | 1 + tools/lib/bpf/btf.c | 196 ++++++++++++++++++++++++--- tools/lib/bpf/btf.h | 3 + tools/lib/bpf/btf_dump.c | 2 +- tools/lib/bpf/btf_relocate.c | 2 +- tools/lib/bpf/gen_loader.c | 187 +++++++++++++++++++------ tools/lib/bpf/libbpf.c | 54 ++++++-- tools/lib/bpf/libbpf.map | 2 + tools/lib/bpf/libbpf_internal.h | 48 ++++++- tools/lib/bpf/linker.c | 92 ++++++++++--- tools/lib/bpf/relo_core.c | 2 +- tools/lib/bpf/skel_internal.h | 3 +- tools/testing/selftests/bpf/Makefile | 7 +- 13 files changed, 502 insertions(+), 97 deletions(-) -- 2.34.1

3 weeks, 4 days

4
27
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror August 2024