October 2023 - Linux-kselftest-mirror

[PATCH] KVM: selftests: add -MP to CFLAGS

by David Woodhouse

From: David Woodhouse <dwmw(a)amazon.co.uk> Using -MD without -MP causes build failures when a header file is deleted or moved. With -MP, the compiler will emit phony targets for the header files it lists as dependencies, and the Makefiles won't refuse to attempt to rebuild a C unit which no longer includes the deleted header. Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> --- tools/testing/selftests/kvm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index a3bb36fb3cfc..20ea549da570 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -211,7 +211,7 @@ else LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/$(ARCH)/include endif CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \ - -Wno-gnu-variable-sized-type-not-at-end -MD\ + -Wno-gnu-variable-sized-type-not-at-end -MD -MP \ -fno-builtin-memcmp -fno-builtin-memcpy -fno-builtin-memset \ -fno-builtin-strnlen \ -fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE) \ -- 2.41.0

20 minutes

3
5
0 0

[PATCH] selftests: core: include linux/close_range.h for CLOSE_RANGE_* macros

by Muhammad Usama Anjum

Correct header file is needed for getting CLOSE_RANGE_* macros. Previously it was tested with newer glibc which didn't show the need to include the header which was a mistake. Fixes: ec54424923cf ("selftests: core: remove duplicate defines") Reported-by: Aishwarya TCV <aishwarya.tcv(a)arm.com> Link: https://lore.kernel.org/all/7161219e-0223-d699-d6f3-81abd9abf13b@arm.com Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- tools/testing/selftests/core/close_range_test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/core/close_range_test.c b/tools/testing/selftests/core/close_range_test.c index 534576f06df1c..c59e4adb905df 100644 --- a/tools/testing/selftests/core/close_range_test.c +++ b/tools/testing/selftests/core/close_range_test.c @@ -12,6 +12,7 @@ #include <syscall.h> #include <unistd.h> #include <sys/resource.h> +#include <linux/close_range.h> #include "../kselftest_harness.h" #include "../clone3/clone3_selftests.h" -- 2.42.0

14 hours, 30 minutes

1
1
0 0

[PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space

by Lu Baolu

Hi folks, This series implements the functionality of delivering IO page faults to user space through the IOMMUFD framework for nested translation. Nested translation is a hardware feature that supports two-stage translation tables for IOMMU. The second-stage translation table is managed by the host VMM, while the first-stage translation table is owned by user space. This allows user space to control the IOMMU mappings for its devices. When an IO page fault occurs on the first-stage translation table, the IOMMU hardware can deliver the page fault to user space through the IOMMUFD framework. User space can then handle the page fault and respond to the device top-down through the IOMMUFD. This allows user space to implement its own IO page fault handling policies. User space indicates its capability of handling IO page faults by setting the IOMMU_HWPT_ALLOC_IOPF_CAPABLE flag when allocating a hardware page table (HWPT). IOMMUFD will then set up its infrastructure for page fault delivery. On a successful return of HWPT allocation, the user can retrieve and respond to page faults by reading and writing to the file descriptor (FD) returned in out_fault_fd. The iommu selftest framework has been updated to test the IO page fault delivery and response functionality. This series is based on the latest implementation of nested translation under discussion [1] and the page fault handling framework refactoring in the IOMMU core [2]. The series and related patches are available on GitHub: [3] [1] https://lore.kernel.org/linux-iommu/20230921075138.124099-1-yi.l.liu@intel.… [2] https://lore.kernel.org/linux-iommu/20230928042734.16134-1-baolu.lu@linux.i… [3] https://github.com/LuBaolu/intel-iommu/commits/iommufd-io-pgfault-delivery-… Best regards, baolu Change log: v2: - Move all iommu refactoring patches into a sparated series and discuss it in a different thread. The latest patch series [v6] is available at https://lore.kernel.org/linux-iommu/20230928042734.16134-1-baolu.lu@linux.i… - We discussed the timeout of the pending page fault messages. We agreed that we shouldn't apply any timeout policy for the page fault handling in user space. https://lore.kernel.org/linux-iommu/20230616113232.GA84678@myrica/ - Jason suggested that we adopt a simple file descriptor interface for reading and responding to I/O page requests, so that user space applications can improve performance using io_uring. https://lore.kernel.org/linux-iommu/ZJWjD1ajeem6pK3I@ziepe.ca/ v1: https://lore.kernel.org/linux-iommu/20230530053724.232765-1-baolu.lu@linux.… Lu Baolu (6): iommu: Add iommu page fault cookie helpers iommufd: Add iommu page fault uapi data iommufd: Initializing and releasing IO page fault data iommufd: Deliver fault messages to user space iommufd/selftest: Add IOMMU_TEST_OP_TRIGGER_IOPF test support iommufd/selftest: Add coverage for IOMMU_TEST_OP_TRIGGER_IOPF include/linux/iommu.h | 9 + drivers/iommu/iommu-priv.h | 15 + drivers/iommu/iommufd/iommufd_private.h | 12 + drivers/iommu/iommufd/iommufd_test.h | 8 + include/uapi/linux/iommufd.h | 65 +++++ tools/testing/selftests/iommu/iommufd_utils.h | 66 ++++- drivers/iommu/io-pgfault.c | 50 ++++ drivers/iommu/iommufd/device.c | 69 ++++- drivers/iommu/iommufd/hw_pagetable.c | 260 +++++++++++++++++- drivers/iommu/iommufd/selftest.c | 56 ++++ tools/testing/selftests/iommu/iommufd.c | 24 +- .../selftests/iommu/iommufd_fail_nth.c | 2 +- 12 files changed, 620 insertions(+), 16 deletions(-) -- 2.34.1

16 hours, 56 minutes

4
12
0 0

[RFC] drm/tests: annotate intentional stack trace in drm_test_rect_calc_hscale()

by Dan Carpenter

We have started printing more and more intentional stack traces. Whether it's testing KASAN is able to detect use after frees or it's part of a kunit test. These stack traces can be problematic. They suddenly show up as a new failure. Now the test team has to contact the developers. A bunch of people have to investigate the bug. We finally decide that it's intentional so now the test team has to update their filter scripts to mark it as intentional. These filters are ad-hoc because there is no standard format for warnings. A better way would be to mark it as intentional from the start. Here, I have marked the beginning and the end of the trace. It's more tricky for things like lkdtm_FORTIFY_MEM_MEMBER() where the flow doesn't reach the end of the function. I guess I would print a different warning for stack traces that can't have a "Intentional warning finished\n" message at the end. I haven't actually tested this patch... Daniel, do you have a list of intentional stack traces we could annotate? Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> --- drivers/gpu/drm/tests/drm_rect_test.c | 2 ++ include/kunit/test.h | 3 +++ 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c index 76332cd2ead8..367738254493 100644 --- a/drivers/gpu/drm/tests/drm_rect_test.c +++ b/drivers/gpu/drm/tests/drm_rect_test.c @@ -409,8 +409,10 @@ static void drm_test_rect_calc_hscale(struct kunit *test) const struct drm_rect_scale_case *params = test->param_value; int scaling_factor; + START_INTENTIONAL_WARNING(); scaling_factor = drm_rect_calc_hscale(&params->src, &params->dst, params->min_range, params->max_range); + END_INTENTIONAL_WARNING(); KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor); } diff --git a/include/kunit/test.h b/include/kunit/test.h index 20ed9f9275c9..1f01d4c81055 100644 --- a/include/kunit/test.h +++ b/include/kunit/test.h @@ -337,6 +337,9 @@ void __kunit_test_suites_exit(struct kunit_suite **suites, int num_suites); void kunit_exec_run_tests(struct kunit_suite_set *suite_set, bool builtin); void kunit_exec_list_tests(struct kunit_suite_set *suite_set, bool include_attr); +#define START_INTENTIONAL_WARNING() pr_info("Triggering a stack trace\n") +#define END_INTENTIONAL_WARNING() pr_info("Intentional warning finished\n") + #if IS_BUILTIN(CONFIG_KUNIT) int kunit_run_all_tests(void); #else -- 2.42.0

1 day, 10 hours

4
5
0 0

[PATCH 0/5] pstore: add tty frontend and multi-backend

by Yuanhe Shu

In public cloud scenario, if kdump service works abnormally, users cannot get vmcore. Without vmcore, user has no idea why the kernel crashed. Meanwhile, there is no additional information to find the reason why the kdump service is abnormal. One way is to obtain console messages through VNC. The drawback is that VNC is real-time, if user missed the timing to get the VNC output, the crash needs to be retriggered. Another way is to enable the console frontend of pstore and record the console messages to the pstore backend. On the one hand, the console logs only contain kernel printk logs and does not cover user-mode print logs. Although we can redirect user-mode logs to the pmsg frontend provided by pstore, user-mode information related to booting and kdump service vary from systemd, kdump.sh, and so on which makes redirection troublesome. So we added a tty frontend and save all logs of tty driver to the pstore backend. Another problem is that currently pstore only supports a single backend. For debugging kdump problems, we hope to save the console logs and tty logs to the ramoops backend of pstore, as it will not be lost after rebooting. If the user has enabled another backend, the ramoops backend will not be registered. To this end, we add the multi-backend function to support simultaneous registration of multiple backends. Based on the above changes, we can enable pstore in the crashdump kernel and save the console logs and tty logs to the ramoops backend of pstore. After rebooting, we can view the relevant logs by mounting the pstore file system. Furthermore, we also modified kexec-tools referring to crash-utils for reading memory, so that pstore ramoops information can be read without enabling pstore in first kernel. As we set the address and size of ramoops, as well as the sizes of console and tty, we can infer the physical address of console logs and tty logs in memory. Referring to the read method of crash-utils, the console logs and tty logs are read from the memory, user can get pstore debug information without affecting the first kernel at all. kexec-tools modification can be seen at https://github.com/shuyuanmen/kexec-tools/blob/main/Add-pstore-segment.patch Yuanhe Shu (5): pstore: add tty frontend pstore: add multi-backends support pstore: add subdirs for multi-backends pstore: remove the module parameter "backend" tools/pstore: update pstore selftests drivers/tty/n_tty.c | 1 + fs/pstore/Kconfig | 23 ++ fs/pstore/Makefile | 2 + fs/pstore/blk.c | 10 + fs/pstore/ftrace.c | 22 +- fs/pstore/inode.c | 86 ++++++- fs/pstore/internal.h | 16 +- fs/pstore/platform.c | 238 ++++++++++++-------- fs/pstore/pmsg.c | 23 +- fs/pstore/ram.c | 40 +++- fs/pstore/tty.c | 56 +++++ fs/pstore/zone.c | 42 +++- include/linux/pstore.h | 33 +++ include/linux/pstore_blk.h | 3 + include/linux/pstore_ram.h | 1 + include/linux/pstore_zone.h | 2 + include/linux/tty.h | 14 ++ tools/testing/selftests/pstore/common_tests | 4 - 18 files changed, 500 insertions(+), 116 deletions(-) create mode 100644 fs/pstore/tty.c -- 2.39.3

5 days, 4 hours

4
9
0 0

[RFC PATCH 0/2] Add a test to verify device probing on ACPI platforms

by Laura Nao

Regressions that prevent a driver from probing a device can significantly affect the functionality of a platform. A kselftest to verify if devices on a DT-based platform are probed correctly was recently introduced [1], but no such generic test is available for ACPI platforms yet. bootrr [2] provides device probe testing, but relies on a pre-defined list of the peripherals present on each DUT. On ACPI based hardware, a complete description of the platform is provided to the OS by the system firmware. ACPI namespace objects are mapped by the Linux ACPI subsystem into a device tree in /sys/devices/LNXSYSTEM:00; the information in this subtree can be parsed to build a list of the hw peripherals present on the DUT dynamically. This series adds a test to verify if the devices declared in the ACPI namespace and supported by the kernel are probed correctly. This work follows a similar approach to [1], adapted for the ACPI use case. The first patch introduces a script that builds a list of all ACPI device IDs supported by the kernel, by inspecting the acpi_device_id structs in the sources. This list can be used to avoid testing ACPI-enumerated devices that don't have a matching driver in the kernel. This script was highly inspired by the dt-extract-compatibles script [3]. In the second patch, a new kselftest is added. It parses the /sys/devices/LNXSYSTEM:00 tree to obtain a list of all platform peripherals and verifies which of those, if supported, are correctly bound to a driver. Feedback is much appreciated, Thank you, Laura [1] https://lore.kernel.org/all/20230828211424.2964562-1-nfraprado@collabora.co… [2] https://github.com/kernelci/bootr [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scr… Laura Nao (2): acpi: Add script to extract ACPI device ids in the kernel kselftest: Add test to detect unprobed devices on ACPI platforms MAINTAINERS | 2 + scripts/acpi/acpi-extract-ids | 60 +++++++++++++++ tools/testing/selftests/Makefile | 1 + tools/testing/selftests/acpi/.gitignore | 2 + tools/testing/selftests/acpi/Makefile | 23 ++++++ .../selftests/acpi/test_unprobed_devices.sh | 75 +++++++++++++++++++ 6 files changed, 163 insertions(+) create mode 100755 scripts/acpi/acpi-extract-ids create mode 100644 tools/testing/selftests/acpi/.gitignore create mode 100644 tools/testing/selftests/acpi/Makefile create mode 100755 tools/testing/selftests/acpi/test_unprobed_devices.sh -- 2.30.2

5 days, 10 hours

2
7
0 0

[PATCH v3 0/9] RISCV: Add kvm Sstc timer selftests

by Haibo Xu

The RISC-V arch_timer selftests is used to validate Sstc timer functionality in a guest, which sets up periodic timer interrupts and check the basic interrupt status upon its receipt. This KVM selftests was ported from aarch64 arch_timer and tested with Linux v6.6-rc1 on a Qemu riscv64 virt machine. --- Changed since v2: * Rebase to Linux 6.6-rc1 * Add separate patch for kvm/Makefile improvement * Move aarch64 specific macros to aarch64/arch_timer.c * Add -DCONFIG_64BIT to kvm/Makefile CFLAGS to ensure only 64bit registers were available in csr.h * Avoid some #ifdef in kvm/arch_timer.c by setting some aarch64 specific variable to 0 on risc-v Haibo Xu (9): KVM: selftests: Unify the codes for guest exception handling KVM: selftests: Unify the makefile rule for split targets KVM: arm64: selftests: Split arch_timer test code tools: riscv: Add header file csr.h KVM: riscv: selftests: Switch to use macro from csr.h KVM: riscv: selftests: Add exception handling support KVM: riscv: selftests: Add guest helper to get vcpu id KVM: riscv: selftests: Change vcpu_has_ext to a common function KVM: riscv: selftests: Add sstc timer test tools/arch/riscv/include/asm/csr.h | 521 ++++++++++++++++++ tools/testing/selftests/kvm/Makefile | 14 +- .../selftests/kvm/aarch64/arch_timer.c | 291 +--------- .../selftests/kvm/aarch64/debug-exceptions.c | 4 +- .../selftests/kvm/aarch64/page_fault_test.c | 4 +- .../testing/selftests/kvm/aarch64/vgic_irq.c | 4 +- tools/testing/selftests/kvm/arch_timer.c | 250 +++++++++ .../selftests/kvm/include/aarch64/processor.h | 12 +- .../selftests/kvm/include/kvm_util_base.h | 9 + .../selftests/kvm/include/riscv/arch_timer.h | 80 +++ .../selftests/kvm/include/riscv/processor.h | 63 ++- .../testing/selftests/kvm/include/test_util.h | 2 + .../selftests/kvm/include/timer_test.h | 43 ++ .../selftests/kvm/include/x86_64/processor.h | 5 - .../selftests/kvm/lib/aarch64/processor.c | 6 +- .../selftests/kvm/lib/riscv/handlers.S | 101 ++++ .../selftests/kvm/lib/riscv/processor.c | 86 +++ .../selftests/kvm/lib/x86_64/processor.c | 4 +- .../testing/selftests/kvm/riscv/arch_timer.c | 107 ++++ .../selftests/kvm/riscv/get-reg-list.c | 16 +- tools/testing/selftests/kvm/x86_64/amx_test.c | 4 +- .../selftests/kvm/x86_64/fix_hypercall_test.c | 4 +- .../selftests/kvm/x86_64/hyperv_evmcs.c | 4 +- .../selftests/kvm/x86_64/hyperv_features.c | 8 +- .../testing/selftests/kvm/x86_64/hyperv_ipi.c | 6 +- .../selftests/kvm/x86_64/kvm_pv_test.c | 4 +- .../selftests/kvm/x86_64/monitor_mwait_test.c | 4 +- .../kvm/x86_64/pmu_event_filter_test.c | 8 +- .../smaller_maxphyaddr_emulation_test.c | 4 +- .../selftests/kvm/x86_64/svm_int_ctl_test.c | 4 +- .../kvm/x86_64/svm_nested_shutdown_test.c | 4 +- .../kvm/x86_64/svm_nested_soft_inject_test.c | 4 +- .../kvm/x86_64/ucna_injection_test.c | 8 +- .../kvm/x86_64/userspace_msr_exit_test.c | 4 +- .../vmx_exception_with_invalid_guest_state.c | 4 +- .../selftests/kvm/x86_64/vmx_pmu_caps_test.c | 4 +- .../selftests/kvm/x86_64/xapic_ipi_test.c | 4 +- .../selftests/kvm/x86_64/xcr0_cpuid_test.c | 4 +- .../selftests/kvm/x86_64/xen_shinfo_test.c | 4 +- 39 files changed, 1338 insertions(+), 374 deletions(-) create mode 100644 tools/arch/riscv/include/asm/csr.h create mode 100644 tools/testing/selftests/kvm/arch_timer.c create mode 100644 tools/testing/selftests/kvm/include/riscv/arch_timer.h create mode 100644 tools/testing/selftests/kvm/include/timer_test.h create mode 100644 tools/testing/selftests/kvm/lib/riscv/handlers.S create mode 100644 tools/testing/selftests/kvm/riscv/arch_timer.c -- 2.34.1

6 days, 23 hours

4
27
0 0

[RFC PATCH v2 0/7] tun: Introduce virtio-net hashing feature

by Akihiko Odaki

virtio-net have two usage of hashes: one is RSS and another is hash reporting. Conventionally the hash calculation was done by the VMM. However, computing the hash after the queue was chosen defeats the purpose of RSS. Another approach is to use eBPF steering program. This approach has another downside: it cannot report the calculated hash due to the restrictive nature of eBPF. Extend the steering program feature by introducing a dedicated program type: BPF_PROG_TYPE_VNET_HASH. This program type is capable to report the hash value and the queue to use at the same time. This is a rewrite of a RFC patch series submitted by Yuri Benditovich that incorporates feedbacks for the series and V1 of this series: https://lore.kernel.org/lkml/20210112194143.1494-1-yuri.benditovich@daynix.… QEMU patched to use this new feature is available at: https://github.com/daynix/qemu/tree/akihikodaki/bpf The QEMU patches will soon be submitted to the upstream as RFC too. V1 -> V2: Changed to introduce a new BPF program type. Akihiko Odaki (7): bpf: Introduce BPF_PROG_TYPE_VNET_HASH bpf: Add vnet_hash members to __sk_buff skbuff: Introduce SKB_EXT_TUN_VNET_HASH virtio_net: Add virtio_net_hdr_v1_hash_from_skb() tun: Support BPF_PROG_TYPE_VNET_HASH selftests/bpf: Test BPF_PROG_TYPE_VNET_HASH vhost_net: Support VIRTIO_NET_F_HASH_REPORT Documentation/bpf/bpf_prog_run.rst | 1 + Documentation/bpf/libbpf/program_types.rst | 2 + drivers/net/tun.c | 158 +++++-- drivers/vhost/net.c | 16 +- include/linux/bpf_types.h | 2 + include/linux/filter.h | 7 + include/linux/skbuff.h | 10 + include/linux/virtio_net.h | 22 + include/uapi/linux/bpf.h | 5 + kernel/bpf/verifier.c | 6 + net/core/filter.c | 86 +++- net/core/skbuff.c | 3 + tools/include/uapi/linux/bpf.h | 5 + tools/lib/bpf/libbpf.c | 2 + tools/testing/selftests/bpf/config | 1 + tools/testing/selftests/bpf/config.aarch64 | 1 - .../selftests/bpf/prog_tests/vnet_hash.c | 385 ++++++++++++++++++ tools/testing/selftests/bpf/progs/vnet_hash.c | 16 + 18 files changed, 681 insertions(+), 47 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/vnet_hash.c create mode 100644 tools/testing/selftests/bpf/progs/vnet_hash.c -- 2.42.0

1 week

5
21
0 0

[RFC 0/7] Add SIOV virtual device support

by Yi Liu

Intel SIOV allows creating virtual devices of which the vRID is represented by a pasid of a physical device. It is called as SIOV virtual device in this series. Such devices can be bound to an iommufd as physical device does and then later be attached to an IOAS/hwpt using that pasid. Such PASIDs are called as default pasid. iommufd has already supported pasid attach[1]. So a simple way to support SIOV virtual device attachment is to let device driver call the iommufd_device_pasid_attach() and pass in the default pasid for the virtual device. This should work for now, but it may have problem if iommufd core wants to differentiate the default pasids with other kind of pasids (e.g. pasid given by userspace). In the later forwarding page request to userspace, the default pasids are not supposed to send to userspace as default pasids are mainly used by the SIOV device driver. With above reason, this series chooses to have a new API to bind the default pasid to iommufd, and extends the iommufd_device_attach() to convert the attachment to be pasid attach with the default pasid. Device drivers (e.g. VFIO) that support SIOV shall call the below APIs to interact with iommufd: - iommufd_device_bind_pasid(): Bind virtual device (a pasid of a device) to iommufd; - iommufd_device_attach(): Attach a SIOV virtual device to IOAS/HWPT; - iommufd_device_replace(): Replace IOAS/HWPT of a SIOV virtual device; - iommufd_device_detach(): Detach IOAS/HWPT of a SIOV virtual device; - iommufd_device_unbind(): Unbind virtual device from iommufd; For vfio devices, the device drivers that support SIOV should: - use below API to register vdev for SIOV virtual device vfio_register_pasid_iommu_dev() - use below API to bind vdev to iommufd in .bind_iommufd() callback iommufd_device_bind_pasid() - allocate pasid by itself before calling iommufd_device_bind_pasid() Complete code can be found at[2] [1] https://lore.kernel.org/linux-iommu/20230926092651.17041-1-yi.l.liu@intel.c… [2] https://github.com/yiliu1765/iommufd/tree/iommufd_pasid_siov Regards, Yi Liu Kevin Tian (5): iommufd: Handle unsafe interrupts in a separate function iommufd: Introduce iommufd_alloc_device() iommufd: Add iommufd_device_bind_pasid() iommufd: Support attach/replace for SIOV virtual device {dev, pasid} vfio: Add vfio_register_pasid_iommu_dev() Yi Liu (2): iommufd/selftest: Extend IOMMU_TEST_OP_MOCK_DOMAIN to pass in pasid iommufd/selftest: Add test coverage for SIOV virtual device drivers/iommu/iommufd/device.c | 163 ++++++++++++++---- drivers/iommu/iommufd/iommufd_private.h | 7 + drivers/iommu/iommufd/iommufd_test.h | 2 + drivers/iommu/iommufd/selftest.c | 10 +- drivers/vfio/group.c | 18 ++ drivers/vfio/vfio.h | 8 + drivers/vfio/vfio_main.c | 10 ++ include/linux/iommufd.h | 3 + include/linux/vfio.h | 1 + tools/testing/selftests/iommu/iommufd.c | 75 ++++++-- .../selftests/iommu/iommufd_fail_nth.c | 42 ++++- tools/testing/selftests/iommu/iommufd_utils.h | 21 ++- 12 files changed, 296 insertions(+), 64 deletions(-) -- 2.34.1

1 week

4
23
0 0

[PATCH v2 0/7] Fix Python string escapes

by Benjamin Gray

Changes from v1: * Dropped some changes that were independently fixed[1] * No longer separate the f strings to their own patch * Use r strings when the value is a regular expression * Updated verification script In retrospect a script to find the instances and apply fixes isn't that useful for review, so the attached script this time just looks for differences in the AST. Apply the series and run the script, with the two references to compare as arguments. There are some intentional changes to the AST now though, as the r strings turn '\t' from a single character tab into a backslash and 't' character pair (similar for '\n'). This does not affect the correctness of the regular expression though. v1: https://lore.kernel.org/all/20230814060704.79655-1-bgray@linux.ibm.com/ [1]: https://lore.kernel.org/all/20230816122133.1231599-1-vishalc@linux.ibm.com/ --- #!/usr/bin/env python3 """ Verify Python syntax trees are equivalent between two references """ import argparse import ast from pathlib import Path import subprocess as sp def read_file(path: Path, ref: str) -> str: return sp.run(f"git show {ref}:{path}", stdout=sp.PIPE, shell=True, encoding="utf-8", check=True).stdout parser = argparse.ArgumentParser("Compare Python ASTs between revisions") parser.add_argument("ref1", type=str, help="First revision to use") parser.add_argument("ref2", type=str, help="Second revision to use") args = parser.parse_args() for pyfile in Path(".").glob("**/*.py"): try: ref1_content = read_file(pyfile, args.ref1) ref2_content = read_file(pyfile, args.ref2) except Exception as e: print(f"ERROR:{pyfile}: Failed to read ({e})") continue try: ref1_syntax = ast.parse(ref1_content, filename=pyfile) ref2_syntax = ast.parse(ref2_content, filename=pyfile) except SyntaxError as e: print(f"ERROR:{pyfile}: Failed to parse, is it Python3? ({e})") continue if ast.dump(ref1_syntax) != ast.dump(ref2_syntax): print(f"ERROR:{pyfile}: Revisions have different AST") cmd = f"diff <(git show {args.ref1}:{pyfile} | python -m ast) <(git show {args.ref2}:{pyfile} | python -m ast)" print(cmd) sp.run(cmd, shell=True) continue Benjamin Gray (7): ia64: fix Python string escapes Documentation/sphinx: fix Python string escapes drivers/comedi: fix Python string escapes scripts: fix Python string escapes tools/perf: fix Python string escapes tools/power: fix Python string escapes selftests/bpf: fix Python string escapes Documentation/sphinx/cdomain.py | 2 +- Documentation/sphinx/kernel_abi.py | 2 +- Documentation/sphinx/kernel_feat.py | 2 +- Documentation/sphinx/kerneldoc.py | 2 +- Documentation/sphinx/maintainers_include.py | 8 +++--- arch/ia64/scripts/unwcheck.py | 2 +- .../ni_routing/tools/convert_csv_to_c.py | 2 +- scripts/clang-tools/gen_compile_commands.py | 2 +- scripts/gdb/linux/symbols.py | 2 +- tools/perf/pmu-events/jevents.py | 2 +- .../scripts/python/arm-cs-trace-disasm.py | 4 +-- tools/perf/scripts/python/compaction-times.py | 2 +- .../scripts/python/exported-sql-viewer.py | 4 +-- tools/power/pm-graph/bootgraph.py | 12 ++++----- .../selftests/bpf/test_bpftool_synctypes.py | 26 +++++++++---------- tools/testing/selftests/bpf/test_offload.py | 2 +- 16 files changed, 38 insertions(+), 38 deletions(-) -- 2.41.0

1 week, 1 day

6
14
0 0

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror October 2023