March 2024 - Linux-kselftest-mirror

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

by Laura Nao

Hello, This v2 addresses some issues observed when running the ACPI probe kselftest proposed in v1[1] across various devices and improves the overall reliability of the test. The acpi-extract-ids script has been improved to: - Parse both .c and .h files - Add an option to print only IDs matched by a driver (i.e. defined in an ACPI match tables or in lists of IDs provided by the drivers) The test_unprobed_devices.sh script relies on sysfs information to determine if a device was successfully bound to a driver. Not all devices listed in /sys/devices are expected to have a driver folder, so the script has been adjusted to handle these cases and avoid generating false negatives. The test_unprobed_devices.sh test script logic has been modified to: - Check the status attribute (when available) to exclusively test hardware devices that are physically present, enabled and operational - Traverse only ACPI objects with a physical_node* link, to ensure testing of correctly enumerated devices - Skip devices whose HID or CID are not matched by any driver, as determined by the list generated through the acpi-extract-ids script - Skip devices with HID or CID listed in the ignored IDs list. This list has been added to contain IDs of devices that don't require a driver or cannot be represented as platform devices (e.g. ACPI container and module devices). - Skip devices that are natively enumerated and don't need a driver, such as certain PCI bridges - Skip devices unassigned to any subsystem, devices linked to other devices and class devices Some of the heuristics used by the script are suboptimal and might require adjustments over time. This kind of tests would greatly benefit from a dedicated interface that exposes information about devices expected to be matched by drivers and their probe status. Discussion regarding this matter was initiated in v1. As of now, I have not identified a suitable method for exposing this information; I plan on submitting a separate RFC to propose some options and engage in discussion. Meanwhile, this v2 focuses on utilizing already available information to provide an ACPI equivalent of the existing DT kselftest [2]. Adding in CC the people involved in the discussion at Plumbers [3], feel free to add anyone that might be interested in this. This series depends on: - https://lore.kernel.org/all/20240102141528.169947-1-laura.nao@collabora.com… - https://lore.kernel.org/all/20240131-ktap-sh-helpers-extend-v1-0-98ffb46871… Thanks, Laura [1] https://lore.kernel.org/all/20230925155806.1812249-2-laura.nao@collabora.co… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/too… [3] https://www.youtube.com/watch?v=oE73eVSyFXQ&t=9377s Original cover letter: 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 [4], but no such generic test is available for ACPI platforms yet. bootrr [5] 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 [4], 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 [6]. 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 [4] https://lore.kernel.org/all/20230828211424.2964562-1-nfraprado@collabora.co… [5] https://github.com/kernelci/bootr [6] 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 | 99 +++++++++++++ tools/testing/selftests/Makefile | 1 + tools/testing/selftests/acpi/.gitignore | 1 + tools/testing/selftests/acpi/Makefile | 21 +++ tools/testing/selftests/acpi/id_ignore_list | 3 + .../selftests/acpi/test_unprobed_devices.sh | 138 ++++++++++++++++++ 7 files changed, 265 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 100644 tools/testing/selftests/acpi/id_ignore_list create mode 100755 tools/testing/selftests/acpi/test_unprobed_devices.sh -- 2.30.2

11 months, 4 weeks

1
3
0 0

[PATCH v4 00/10] Add support for synchronous signals on perf events

by Marco Elver

The perf subsystem today unifies various tracing and monitoring features, from both software and hardware. One benefit of the perf subsystem is automatically inheriting events to child tasks, which enables process-wide events monitoring with low overheads. By default perf events are non-intrusive, not affecting behaviour of the tasks being monitored. For certain use-cases, however, it makes sense to leverage the generality of the perf events subsystem and optionally allow the tasks being monitored to receive signals on events they are interested in. This patch series adds the option to synchronously signal user space on events. To better support process-wide synchronous self-monitoring, without events propagating to children that do not share the current process's shared environment, two pre-requisite patches are added to optionally restrict inheritance to CLONE_THREAD, and remove events on exec (without affecting the parent). Examples how to use these features can be found in the tests added at the end of the series. In addition to the tests added, the series has also been subjected to syzkaller fuzzing (focus on 'kernel/events/' coverage). Motivation and Example Uses --------------------------- 1. Our immediate motivation is low-overhead sampling-based race detection for user space [1]. By using perf_event_open() at process initialization, we can create hardware breakpoint/watchpoint events that are propagated automatically to all threads in a process. As far as we are aware, today no existing kernel facility (such as ptrace) allows us to set up process-wide watchpoints with minimal overheads (that are comparable to mprotect() of whole pages). 2. Other low-overhead error detectors that rely on detecting accesses to certain memory locations or code, process-wide and also only in a specific set of subtasks or threads. [1] https://llvm.org/devmtg/2020-09/slides/Morehouse-GWP-Tsan.pdf Other ideas for use-cases we found interesting, but should only illustrate the range of potential to further motivate the utility (we're sure there are more): 3. Code hot patching without full stop-the-world. Specifically, by setting a code breakpoint to entry to the patched routine, then send signals to threads and check that they are not in the routine, but without stopping them further. If any of the threads will enter the routine, it will receive SIGTRAP and pause. 4. Safepoints without mprotect(). Some Java implementations use "load from a known memory location" as a safepoint. When threads need to be stopped, the page containing the location is mprotect()ed and threads get a signal. This could be replaced with a watchpoint, which does not require a whole page nor DTLB shootdowns. 5. Threads receiving signals on performance events to throttle/unthrottle themselves. 6. Tracking data flow globally. Changelog --------- v4: * Fix for parent and child racing to exit in sync_child_event(). * Fix race between irq_work running and task's sighand being released by release_task(). * Generalize setting si_perf and si_addr independent of event type; introduces perf_event_attr::sig_data, which can be set by user space to be propagated to si_perf. * Warning in perf_sigtrap() if ctx->task and current mismatch; we expect this on architectures that do not properly implement arch_irq_work_raise(). * Require events that want sigtrap to be associated with a task. * Dropped "perf: Add breakpoint information to siginfo on SIGTRAP" in favor of more generic solution (perf_event_attr::sig_data). v3: * Add patch "perf: Rework perf_event_exit_event()" to beginning of series, courtesy of Peter Zijlstra. * Rework "perf: Add support for event removal on exec" based on the added "perf: Rework perf_event_exit_event()". * Fix kselftests to work with more recent libc, due to the way it forces using the kernel's own siginfo_t. * Add basic perf-tool built-in test. v2/RFC: https://lkml.kernel.org/r/20210310104139.679618-1-elver@google.com * Patch "Support only inheriting events if cloned with CLONE_THREAD" added to series. * Patch "Add support for event removal on exec" added to series. * Patch "Add kselftest for process-wide sigtrap handling" added to series. * Patch "Add kselftest for remove_on_exec" added to series. * Implicitly restrict inheriting events if sigtrap, but the child was cloned with CLONE_CLEAR_SIGHAND, because it is not generally safe if the child cleared all signal handlers to continue sending SIGTRAP. * Various minor fixes (see details in patches). v1/RFC: https://lkml.kernel.org/r/20210223143426.2412737-1-elver@google.com Pre-series: The discussion at [2] led to the changes in this series. The approach taken in "Add support for SIGTRAP on perf events" to trigger the signal was suggested by Peter Zijlstra in [3]. [2] https://lore.kernel.org/lkml/CACT4Y+YPrXGw+AtESxAgPyZ84TYkNZdP0xpocX2jwVAbZ… [3] https://lore.kernel.org/lkml/YBv3rAT566k+6zjg@hirez.programming.kicks-ass.n… Marco Elver (9): perf: Apply PERF_EVENT_IOC_MODIFY_ATTRIBUTES to children perf: Support only inheriting events if cloned with CLONE_THREAD perf: Add support for event removal on exec signal: Introduce TRAP_PERF si_code and si_perf to siginfo perf: Add support for SIGTRAP on perf events selftests/perf_events: Add kselftest for process-wide sigtrap handling selftests/perf_events: Add kselftest for remove_on_exec tools headers uapi: Sync tools/include/uapi/linux/perf_event.h perf test: Add basic stress test for sigtrap handling Peter Zijlstra (1): perf: Rework perf_event_exit_event() arch/m68k/kernel/signal.c | 3 + arch/x86/kernel/signal_compat.c | 5 +- fs/signalfd.c | 4 + include/linux/compat.h | 2 + include/linux/perf_event.h | 9 +- include/linux/signal.h | 1 + include/uapi/asm-generic/siginfo.h | 6 +- include/uapi/linux/perf_event.h | 12 +- include/uapi/linux/signalfd.h | 4 +- kernel/events/core.c | 302 +++++++++++++----- kernel/fork.c | 2 +- kernel/signal.c | 11 + tools/include/uapi/linux/perf_event.h | 12 +- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 5 + tools/perf/tests/sigtrap.c | 150 +++++++++ tools/perf/tests/tests.h | 1 + .../testing/selftests/perf_events/.gitignore | 3 + tools/testing/selftests/perf_events/Makefile | 6 + tools/testing/selftests/perf_events/config | 1 + .../selftests/perf_events/remove_on_exec.c | 260 +++++++++++++++ tools/testing/selftests/perf_events/settings | 1 + .../selftests/perf_events/sigtrap_threads.c | 210 ++++++++++++ 23 files changed, 924 insertions(+), 87 deletions(-) create mode 100644 tools/perf/tests/sigtrap.c create mode 100644 tools/testing/selftests/perf_events/.gitignore create mode 100644 tools/testing/selftests/perf_events/Makefile create mode 100644 tools/testing/selftests/perf_events/config create mode 100644 tools/testing/selftests/perf_events/remove_on_exec.c create mode 100644 tools/testing/selftests/perf_events/settings create mode 100644 tools/testing/selftests/perf_events/sigtrap_threads.c -- 2.31.0.208.g409f899ff0-goog

12 months

5
29
0 0

[PATCH] tools/testing/selftests/x86: add dlclose function in the vdso_restorer.c

by liujing

in the main function of vdso_restorer.c,there is a dlopen function, but there is no dlclose function to close the file Signed-off-by: liujing <liujing(a)cmss.chinamobile.com> --- tools/testing/selftests/x86/vdso_restorer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/x86/vdso_restorer.c b/tools/testing/selftests/x86/vdso_restorer.c index fe99f2434155..a0b1155dee31 100644 --- a/tools/testing/selftests/x86/vdso_restorer.c +++ b/tools/testing/selftests/x86/vdso_restorer.c @@ -57,6 +57,8 @@ int main() return 0; } + dlclose(vdso); + memset(&sa, 0, sizeof(sa)); sa.handler = handler_with_siginfo; sa.flags = SA_SIGINFO; -- 2.18.2

12 months

2
1
0 0

[PATCH 0/4] selftests/resctrl: Enable MBM and MBA tests on AMD

by Babu Moger

The MBM (Memory Bandwidth Monitoring) and MBA (Memory Bandwidth Allocation) features are not enabled for AMD systems. The reason was lack of perf counters to compare the resctrl test results. Starting with the commit 25e56847821f ("perf/x86/amd/uncore: Add memory controller support"), AMD now supports the UMC (Unified Memory Controller) perf events. These events can be used to compare the test results. This series adds the support to detect the UMC events and enable MBM/MBA tests for AMD systems. Babu Moger (4): selftests/resctrl: Rename variable imcs and num_of_imcs() to generic names selftests/resctrl: Pass sysfs controller name of the vendor selftests/resctrl: Add support for MBM and MBA tests on AMD selftests/resctrl: Skip the tests if iMC/UMC counters are unavailable tools/testing/selftests/resctrl/resctrl.h | 1 + .../testing/selftests/resctrl/resctrl_tests.c | 16 ++- tools/testing/selftests/resctrl/resctrl_val.c | 105 ++++++++++++++---- 3 files changed, 96 insertions(+), 26 deletions(-) -- 2.34.1

1 year

5
30
0 0

selftests: clone3: clone3_cap_checkpoint_restore fails - Could not set CAP_CHECKPOINT_RESTORE

by Naresh Kamboju

selftests clone3 cap_checkpoint_restore fails on all devices. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> [ 97.198602] audit: type=1701 audit(1651167820.383:12): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1732 comm=\"clone3_cap_chec\" exe=\"/opt/kselftests/default-in-kernel/clone3/clone3_cap_checkpoint_restore\" sig=6 res=1 # selftests: clone3: clone3_cap_checkpoint_restore # TAP version 13 # 1..1 # # Starting 1 tests from 1 test cases. # # RUN global.clone3_cap_checkpoint_restore ... # # clone3_cap_checkpoint_restore.c:155:clone3_cap_checkpoint_restore:Child has PID 1733 # # clone3() syscall supported # cap_set_proc: Operation not permitted # # clone3_cap_checkpoint_restore.c:164:clone3_cap_checkpoint_restore:Expected set_capability() (-1) == 0 (0) # # clone3_cap_checkpoint_restore.c:165:clone3_cap_checkpoint_restore:Could not set CAP_CHECKPOINT_RESTORE # # clone3_cap_checkpoint_restore: Test terminated by assertion # # FAIL global.clone3_cap_checkpoint_restore # not ok 1 global.clone3_cap_checkpoint_restore # # FAILED: 0 / 1 tests passed. # # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0 not ok 4 selftests: clone3: clone3_cap_checkpoint_restore # exit=1 Test details links, https://lkft.validation.linaro.org/scheduler/job/5812724#L2074 Test results comparison link, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20221107/te… https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20221107/te… https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20221107/te… metadata: git_ref: master git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git_sha: d8e87774068af213ab5b058b1b114dc397b577aa git_describe: next-20221107 kernel_version: 6.1.0-rc3 kernel-config: https://builds.tuxbuild.com/2HChVOSNxUpvfAfLTnaK7zyTdUi/config build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/687092361 artifact-location: https://builds.tuxbuild.com/2HChVOSNxUpvfAfLTnaK7zyTdUi toolchain: gcc-11 -- Linaro LKFT https://lkft.linaro.org

1 year

3
3
0 0

[PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

by Helen Koike

Dear Kernel Community, This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a basic test pipeline triggered by code pushes to a GitLab-CI instance. This initial version includes static checks (checkpatch and smatch for now) and build tests across various architectures and configurations. It leverages an integrated cache for efficient build times and introduces a flexible 'scenarios' mechanism for subsystem-specific extensions. tl;dr: check this video to see a quick demo: https://youtu.be/TWiTjhjOuzg, but don't forget to check the "Motivation for this work" below. Your feedback, whether a simple thumbs up or down, is crucial to determine if it is worthwhile to pursue this initiative. GitLab is an Open Source platform that includes integrated CI/CD. The pipeline provided in this patch is designed to work out-of-the-box with any GitLab instance, including the gitlab.com Free Tier. If you reach the limits of the Free Tier, consider using community instances like https://gitlab.freedesktop.org/. Alternatively, you can set up a local runner for more flexibility. The bootstrap-gitlab-runner.sh script included with this patch simplifies this process, enabling you to run tests on your preferred infrastructure, including your own machine. For detailed information, please refer to the documentation included in the patch, or check the rendered version here: https://koike.pages.collabora.com/-/linux/-/jobs/298498/artifacts/artifacts… . Motivation for this Work ======================== We all know tests are a major topic in the community, so let's mention the specificities of this approach: 1. **Built-in User Interface:** GitLab CI/CD is growing in popularity and has an user-friendly interface. Our experience with the upstream DRM-CI in the kernel tree (see this blog post [https://www.collabora.com/news-and-blog/blog/2024/02/08/drm-ci-a-gitlab-ci-…] ) has provided insights into how such a system can benefit the wider community. 2. **Distributed Infrastructure:** The proposed GitLab-CI pipeline is designed with a distributed infrastructure model, being possible to run in any gitlab instance. 3. **Reduce regressions:** Fostering a culture where people habitually run validated tests and post their results can prevent many issues in post-merge tests. 4. **Collaborative Testing Environment:** The kernel community is already engaged in numerous testing efforts, including various GitLab-CI pipelines such as DRM-CI, which I maintain, along with other solutions like KernelCI and BPF-CI. This proposal is designed to further stimulate contributions to the evolving testing landscape. Our goal is to establish a comprehensive suite of common tools and files. 5. **Ownership of QA:** Discrepancies between kernel code and outdated tests often lead to misattributed failures, complicating regression tracking. This issue, often arising from neglected or deprioritized test updates, creates uncertainty about the source of failures. Adopting an "always green pipeline" approach, as detailed in this patch's documentation, encourages timely maintenance and validation of tests. This ensures that testing accurately reflects the current state of the kernel, thereby improving the effectiveness of our QA processes. Additionally, if we discover that this method isn't working for us, we can easily remove it from the codebase, as it is primarily contained within the ci/ folder. Future Work =========== **Expanding Static Checks:** We have the opportunity to integrate a variety of static analysis tools, including: - dtbs_checks - sparse - yamllint - dt-doc-validate - coccicheck **Adding Userspace Tests on VMs:** To further our testing, we can implement userspace tests that run on virtual machines (VMs), such as: - kselftests - kunit tests - Subsystem-specific tests, customizable in the scenarios. **Leveraging External Test Labs:** We can extend our testing to external labs, similar to what DRM-CI currently does. This includes: - Lava labs - Bare metal labs - Using KernelCI-provided labs **Other integrations** - Submit results to KCIDB **Lightweight Implementation for All Developers:** We aim to design these tests to be lightweight, ensuring developers with limited computing resources can still run essential tests. Resource-intensive tests can be set to trigger manually, rather than automatically, to accommodate diverse development environments. Chat Discussions ================ For those interested in further discussions: **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. **Acknowledgments:** A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red Hat - and KernelCI community for their valuable feedback and support in this proposal. I eagerly await your thoughts and suggestions on this initiative. Also, if you want to see this initiave move faster, we are happy to discuss funding options. Best regards, Helen Koike Helen Koike (3): kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing kci-gitlab: Add documentation kci-gitlab: docs: Add images .gitlab-ci.yml | 2 + Documentation/ci/gitlab-ci/gitlab-ci.rst | 404 ++++++++++++++++++ .../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 159752 bytes .../gitlab-ci/images/new-project-runner.png | Bin 0 -> 607737 bytes .../ci/gitlab-ci/images/pipelines-on-push.png | Bin 0 -> 532143 bytes .../ci/gitlab-ci/images/the-pipeline.png | Bin 0 -> 91675 bytes .../ci/gitlab-ci/images/variables.png | Bin 0 -> 277518 bytes Documentation/index.rst | 7 + MAINTAINERS | 9 + ci/gitlab-ci/bootstrap-gitlab-runner.sh | 55 +++ ci/gitlab-ci/ci-scripts/build-docs.sh | 35 ++ ci/gitlab-ci/ci-scripts/build-kernel.sh | 35 ++ ci/gitlab-ci/ci-scripts/ici-functions.sh | 104 +++++ ci/gitlab-ci/ci-scripts/install-smatch.sh | 13 + .../ci-scripts/parse_commit_message.sh | 27 ++ ci/gitlab-ci/ci-scripts/run-checkpatch.sh | 19 + ci/gitlab-ci/ci-scripts/run-smatch.sh | 45 ++ ci/gitlab-ci/docker-compose.yaml | 18 + ci/gitlab-ci/linux.code-workspace | 11 + ci/gitlab-ci/yml/build.yml | 43 ++ ci/gitlab-ci/yml/cache.yml | 26 ++ ci/gitlab-ci/yml/container.yml | 36 ++ ci/gitlab-ci/yml/gitlab-ci.yml | 71 +++ ci/gitlab-ci/yml/kernel-combinations.yml | 18 + ci/gitlab-ci/yml/scenarios.yml | 12 + ci/gitlab-ci/yml/scenarios/file-systems.yml | 21 + ci/gitlab-ci/yml/scenarios/media.yml | 21 + ci/gitlab-ci/yml/scenarios/network.yml | 21 + ci/gitlab-ci/yml/static-checks.yml | 21 + 29 files changed, 1074 insertions(+) create mode 100644 .gitlab-ci.yml create mode 100644 Documentation/ci/gitlab-ci/gitlab-ci.rst create mode 100644 Documentation/ci/gitlab-ci/images/job-matrix.png create mode 100644 Documentation/ci/gitlab-ci/images/new-project-runner.png create mode 100644 Documentation/ci/gitlab-ci/images/pipelines-on-push.png create mode 100644 Documentation/ci/gitlab-ci/images/the-pipeline.png create mode 100644 Documentation/ci/gitlab-ci/images/variables.png create mode 100755 ci/gitlab-ci/bootstrap-gitlab-runner.sh create mode 100755 ci/gitlab-ci/ci-scripts/build-docs.sh create mode 100755 ci/gitlab-ci/ci-scripts/build-kernel.sh create mode 100644 ci/gitlab-ci/ci-scripts/ici-functions.sh create mode 100755 ci/gitlab-ci/ci-scripts/install-smatch.sh create mode 100755 ci/gitlab-ci/ci-scripts/parse_commit_message.sh create mode 100755 ci/gitlab-ci/ci-scripts/run-checkpatch.sh create mode 100755 ci/gitlab-ci/ci-scripts/run-smatch.sh create mode 100644 ci/gitlab-ci/docker-compose.yaml create mode 100644 ci/gitlab-ci/linux.code-workspace create mode 100644 ci/gitlab-ci/yml/build.yml create mode 100644 ci/gitlab-ci/yml/cache.yml create mode 100644 ci/gitlab-ci/yml/container.yml create mode 100644 ci/gitlab-ci/yml/gitlab-ci.yml create mode 100644 ci/gitlab-ci/yml/kernel-combinations.yml create mode 100644 ci/gitlab-ci/yml/scenarios.yml create mode 100644 ci/gitlab-ci/yml/scenarios/file-systems.yml create mode 100644 ci/gitlab-ci/yml/scenarios/media.yml create mode 100644 ci/gitlab-ci/yml/scenarios/network.yml create mode 100644 ci/gitlab-ci/yml/static-checks.yml -- 2.40.1

1 year

18
57
0 0

[syzbot] WARNING in btrfs_free_reserved_data_space_noquota

by syzbot

Hello, syzbot found the following issue on: HEAD commit: b7b275e60bcd Linux 6.1-rc7 git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=158a7b73880000 kernel config: https://syzkaller.appspot.com/x/.config?x=2325e409a9a893e1 dashboard link: https://syzkaller.appspot.com/bug?extid=adec8406ad17413d4c06 compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=169ccb75880000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17bf7153880000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/525233126d34/disk-b7b275e6.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/e8299bf41400/vmlinux-b7b275e6.… kernel image: https://storage.googleapis.com/syzbot-assets/eebf691dbf6f/bzImage-b7b275e6.… mounted in repro: https://storage.googleapis.com/syzbot-assets/5423c2d2ad62/mount_0.gz The issue was bisected to: commit c814bf958926ff45a9c1e899bd001006ab6cfbae Author: ye xingchen <ye.xingchen(a)zte.com.cn> Date: Tue Aug 16 10:51:06 2022 +0000 powerpc/selftests: Use timersub() for gettimeofday() bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=118c3d03880000 final oops: https://syzkaller.appspot.com/x/report.txt?x=138c3d03880000 console output: https://syzkaller.appspot.com/x/log.txt?x=158c3d03880000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+adec8406ad17413d4c06(a)syzkaller.appspotmail.com Fixes: c814bf958926 ("powerpc/selftests: Use timersub() for gettimeofday()") RDX: 0000000000000001 RSI: 0000000020000280 RDI: 0000000000000005 RBP: 00007ffd32e91c70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000008000000 R11: 0000000000000246 R12: 0000000000000006 R13: 00007ffd32e91cb0 R14: 00007ffd32e91c90 R15: 0000000000000006 </TASK> ------------[ cut here ]------------ WARNING: CPU: 1 PID: 3764 at fs/btrfs/space-info.h:122 btrfs_space_info_free_bytes_may_use fs/btrfs/space-info.h:154 [inline] WARNING: CPU: 1 PID: 3764 at fs/btrfs/space-info.h:122 btrfs_free_reserved_data_space_noquota+0x219/0x2b0 fs/btrfs/delalloc-space.c:179 Modules linked in: CPU: 1 PID: 3764 Comm: syz-executor759 Not tainted 6.1.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:btrfs_space_info_update_bytes_may_use fs/btrfs/space-info.h:122 [inline] RIP: 0010:btrfs_space_info_free_bytes_may_use fs/btrfs/space-info.h:154 [inline] RIP: 0010:btrfs_free_reserved_data_space_noquota+0x219/0x2b0 fs/btrfs/delalloc-space.c:179 Code: 2f 00 74 08 4c 89 ef e8 b5 98 32 fe 49 8b 5d 00 48 89 df 4c 8b 74 24 08 4c 89 f6 e8 21 81 de fd 4c 39 f3 73 16 e8 d7 7e de fd <0f> 0b 31 db 4c 8b 34 24 41 80 3c 2f 00 75 8c eb 92 e8 c1 7e de fd RSP: 0018:ffffc9000443f410 EFLAGS: 00010293 RAX: ffffffff83ac1919 RBX: 00000000005cb000 RCX: ffff888027989d40 RDX: 0000000000000000 RSI: 0000000000800000 RDI: 00000000005cb000 RBP: dffffc0000000000 R08: ffffffff83ac190f R09: fffffbfff1cebe0e R10: fffffbfff1cebe0e R11: 1ffffffff1cebe0d R12: ffff8880774f3800 R13: ffff8880774f3860 R14: 0000000000800000 R15: 1ffff1100ee9e70c FS: 0000555555aaa300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0d98f20140 CR3: 0000000025ccf000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> btrfs_free_reserved_data_space+0x9d/0xd0 fs/btrfs/delalloc-space.c:199 btrfs_dio_iomap_begin+0x8f7/0x1070 fs/btrfs/inode.c:7762 iomap_iter+0x606/0x8a0 fs/iomap/iter.c:74 __iomap_dio_rw+0xd91/0x20d0 fs/iomap/direct-io.c:601 btrfs_dio_write+0x9c/0xe0 fs/btrfs/inode.c:8094 btrfs_direct_write fs/btrfs/file.c:1835 [inline] btrfs_do_write_iter+0x871/0x1260 fs/btrfs/file.c:1980 do_iter_write+0x6c2/0xc20 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x200/0x350 fs/read_write.c:1031 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f0d98ea8ea9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd32e91c38 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f0d98ea8ea9 RDX: 0000000000000001 RSI: 0000000020000280 RDI: 0000000000000005 RBP: 00007ffd32e91c70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000008000000 R11: 0000000000000246 R12: 0000000000000006 R13: 00007ffd32e91cb0 R14: 00007ffd32e91c90 R15: 0000000000000006 </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

1 year

3
3
0 0

[PATCH v6] lib: add basic KUnit test for lib/math

by Daniel Latypov

Add basic test coverage for files that don't require any config options: * part of math.h (what seem to be the most commonly used macros) * gcd.c * lcm.c * int_sqrt.c * reciprocal_div.c (Ignored int_pow.c since it's a simple textbook algorithm.) These tests aren't particularly interesting, but they * provide short and simple examples of parameterized tests * provide a place to add tests for any new files in this dir * are written so adding new test cases to cover edge cases should be easy * looking at code coverage, we hit all the branches in the .c files Signed-off-by: Daniel Latypov <dlatypov(a)google.com> Reviewed-by: David Gow <davidgow(a)google.com> --- Changes since v5: * add in test cases for roundup/rounddown * address misc comments from David Changes since v4: * add in test cases for some math.h macros (abs, round_up/round_down, div_round_down/closest) * use parameterized testing less to keep things terser Changes since v3: * fix `checkpatch.pl --strict` warnings * add test cases for gcd(0,0) and lcm(0,0) * minor: don't test both gcd(a,b) and gcd(b,a) when a == b Changes since v2: mv math_test.c => math_kunit.c Changes since v1: * Rebase and rewrite to use the new parameterized testing support. * misc: fix overflow in literal and inline int_sqrt format string. * related: commit 1f0e943df68a ("Documentation: kunit: provide guidance for testing many inputs") was merged explaining the patterns shown here. * there's an in-flight patch to update it for parameterized testing. --- lib/math/Kconfig | 12 ++ lib/math/Makefile | 2 + lib/math/math_kunit.c | 291 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 305 insertions(+) create mode 100644 lib/math/math_kunit.c diff --git a/lib/math/Kconfig b/lib/math/Kconfig index f19bc9734fa7..a974d4db0f9c 100644 --- a/lib/math/Kconfig +++ b/lib/math/Kconfig @@ -15,3 +15,15 @@ config PRIME_NUMBERS config RATIONAL bool + +config MATH_KUNIT_TEST + tristate "KUnit test for lib/math and math.h" if !KUNIT_ALL_TESTS + depends on KUNIT + default KUNIT_ALL_TESTS + help + This builds unit tests for lib/math and math.h. + + For more information on KUnit and unit tests in general, please refer + to the KUnit documentation in Documentation/dev-tools/kunit/. + + If unsure, say N. diff --git a/lib/math/Makefile b/lib/math/Makefile index be6909e943bd..30abb7a8d564 100644 --- a/lib/math/Makefile +++ b/lib/math/Makefile @@ -4,3 +4,5 @@ obj-y += div64.o gcd.o lcm.o int_pow.o int_sqrt.o reciprocal_div.o obj-$(CONFIG_CORDIC) += cordic.o obj-$(CONFIG_PRIME_NUMBERS) += prime_numbers.o obj-$(CONFIG_RATIONAL) += rational.o + +obj-$(CONFIG_MATH_KUNIT_TEST) += math_kunit.o diff --git a/lib/math/math_kunit.c b/lib/math/math_kunit.c new file mode 100644 index 000000000000..556c23b17c3c --- /dev/null +++ b/lib/math/math_kunit.c @@ -0,0 +1,291 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Simple KUnit suite for math helper funcs that are always enabled. + * + * Copyright (C) 2020, Google LLC. + * Author: Daniel Latypov <dlatypov(a)google.com> + */ + +#include <kunit/test.h> +#include <linux/gcd.h> +#include <linux/kernel.h> +#include <linux/lcm.h> +#include <linux/reciprocal_div.h> + +static void abs_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, abs((char)0), (char)0); + KUNIT_EXPECT_EQ(test, abs((char)42), (char)42); + KUNIT_EXPECT_EQ(test, abs((char)-42), (char)42); + + /* The expression in the macro is actually promoted to an int. */ + KUNIT_EXPECT_EQ(test, abs((short)0), 0); + KUNIT_EXPECT_EQ(test, abs((short)42), 42); + KUNIT_EXPECT_EQ(test, abs((short)-42), 42); + + KUNIT_EXPECT_EQ(test, abs(0), 0); + KUNIT_EXPECT_EQ(test, abs(42), 42); + KUNIT_EXPECT_EQ(test, abs(-42), 42); + + KUNIT_EXPECT_EQ(test, abs(0L), 0L); + KUNIT_EXPECT_EQ(test, abs(42L), 42L); + KUNIT_EXPECT_EQ(test, abs(-42L), 42L); + + KUNIT_EXPECT_EQ(test, abs(0LL), 0LL); + KUNIT_EXPECT_EQ(test, abs(42LL), 42LL); + KUNIT_EXPECT_EQ(test, abs(-42LL), 42LL); + + /* Unsigned types get casted to signed. */ + KUNIT_EXPECT_EQ(test, abs(0ULL), 0LL); + KUNIT_EXPECT_EQ(test, abs(42ULL), 42LL); +} + +static void int_sqrt_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, int_sqrt(0UL), 0UL); + KUNIT_EXPECT_EQ(test, int_sqrt(1UL), 1UL); + KUNIT_EXPECT_EQ(test, int_sqrt(4UL), 2UL); + KUNIT_EXPECT_EQ(test, int_sqrt(5UL), 2UL); + KUNIT_EXPECT_EQ(test, int_sqrt(8UL), 2UL); + KUNIT_EXPECT_EQ(test, int_sqrt(1UL << 30), 1UL << 15); +} + +static void round_up_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, round_up(0, 1), 0); + KUNIT_EXPECT_EQ(test, round_up(1, 2), 2); + KUNIT_EXPECT_EQ(test, round_up(3, 2), 4); + KUNIT_EXPECT_EQ(test, round_up((1 << 30) - 1, 2), 1 << 30); + KUNIT_EXPECT_EQ(test, round_up((1 << 30) - 1, 1 << 29), 1 << 30); +} + +static void round_down_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, round_down(0, 1), 0); + KUNIT_EXPECT_EQ(test, round_down(1, 2), 0); + KUNIT_EXPECT_EQ(test, round_down(3, 2), 2); + KUNIT_EXPECT_EQ(test, round_down((1 << 30) - 1, 2), (1 << 30) - 2); + KUNIT_EXPECT_EQ(test, round_down((1 << 30) - 1, 1 << 29), 1 << 29); +} + +/* These versions can round to numbers that aren't a power of two */ +static void roundup_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, roundup(0, 1), 0); + KUNIT_EXPECT_EQ(test, roundup(1, 2), 2); + KUNIT_EXPECT_EQ(test, roundup(3, 2), 4); + KUNIT_EXPECT_EQ(test, roundup((1 << 30) - 1, 2), 1 << 30); + KUNIT_EXPECT_EQ(test, roundup((1 << 30) - 1, 1 << 29), 1 << 30); + + KUNIT_EXPECT_EQ(test, roundup(3, 2), 4); + KUNIT_EXPECT_EQ(test, roundup(4, 3), 6); +} + +static void rounddown_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, rounddown(0, 1), 0); + KUNIT_EXPECT_EQ(test, rounddown(1, 2), 0); + KUNIT_EXPECT_EQ(test, rounddown(3, 2), 2); + KUNIT_EXPECT_EQ(test, rounddown((1 << 30) - 1, 2), (1 << 30) - 2); + KUNIT_EXPECT_EQ(test, rounddown((1 << 30) - 1, 1 << 29), 1 << 29); + + KUNIT_EXPECT_EQ(test, rounddown(3, 2), 2); + KUNIT_EXPECT_EQ(test, rounddown(4, 3), 3); +} + +static void div_round_up_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, DIV_ROUND_UP(0, 1), 0); + KUNIT_EXPECT_EQ(test, DIV_ROUND_UP(20, 10), 2); + KUNIT_EXPECT_EQ(test, DIV_ROUND_UP(21, 10), 3); + KUNIT_EXPECT_EQ(test, DIV_ROUND_UP(21, 20), 2); + KUNIT_EXPECT_EQ(test, DIV_ROUND_UP(21, 99), 1); +} + +static void div_round_closest_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, DIV_ROUND_CLOSEST(0, 1), 0); + KUNIT_EXPECT_EQ(test, DIV_ROUND_CLOSEST(20, 10), 2); + KUNIT_EXPECT_EQ(test, DIV_ROUND_CLOSEST(21, 10), 2); + KUNIT_EXPECT_EQ(test, DIV_ROUND_CLOSEST(25, 10), 3); +} + +/* Generic test case for unsigned long inputs. */ +struct test_case { + unsigned long a, b; + unsigned long result; +}; + +static struct test_case gcd_cases[] = { + { + .a = 0, .b = 0, + .result = 0, + }, + { + .a = 0, .b = 1, + .result = 1, + }, + { + .a = 2, .b = 2, + .result = 2, + }, + { + .a = 2, .b = 4, + .result = 2, + }, + { + .a = 3, .b = 5, + .result = 1, + }, + { + .a = 3 * 9, .b = 3 * 5, + .result = 3, + }, + { + .a = 3 * 5 * 7, .b = 3 * 5 * 11, + .result = 15, + }, + { + .a = 1 << 21, + .b = (1 << 21) - 1, + .result = 1, + }, +}; + +KUNIT_ARRAY_PARAM(gcd, gcd_cases, NULL); + +static void gcd_test(struct kunit *test) +{ + const char *message_fmt = "gcd(%lu, %lu)"; + const struct test_case *test_param = test->param_value; + + KUNIT_EXPECT_EQ_MSG(test, test_param->result, + gcd(test_param->a, test_param->b), + message_fmt, test_param->a, + test_param->b); + + if (test_param->a == test_param->b) + return; + + /* gcd(a,b) == gcd(b,a) */ + KUNIT_EXPECT_EQ_MSG(test, test_param->result, + gcd(test_param->b, test_param->a), + message_fmt, test_param->b, + test_param->a); +} + +static struct test_case lcm_cases[] = { + { + .a = 0, .b = 0, + .result = 0, + }, + { + .a = 0, .b = 1, + .result = 0, + }, + { + .a = 1, .b = 2, + .result = 2, + }, + { + .a = 2, .b = 2, + .result = 2, + }, + { + .a = 3 * 5, .b = 3 * 7, + .result = 3 * 5 * 7, + }, +}; + +KUNIT_ARRAY_PARAM(lcm, lcm_cases, NULL); + +static void lcm_test(struct kunit *test) +{ + const char *message_fmt = "lcm(%lu, %lu)"; + const struct test_case *test_param = test->param_value; + + KUNIT_EXPECT_EQ_MSG(test, test_param->result, + lcm(test_param->a, test_param->b), + message_fmt, test_param->a, + test_param->b); + + if (test_param->a == test_param->b) + return; + + /* lcm(a,b) == lcm(b,a) */ + KUNIT_EXPECT_EQ_MSG(test, test_param->result, + lcm(test_param->b, test_param->a), + message_fmt, test_param->b, + test_param->a); +} + +struct u32_test_case { + u32 a, b; + u32 result; +}; + +static struct u32_test_case reciprocal_div_cases[] = { + { + .a = 0, .b = 1, + .result = 0, + }, + { + .a = 42, .b = 20, + .result = 2, + }, + { + .a = 42, .b = 9999, + .result = 0, + }, + { + .a = (1 << 16), .b = (1 << 14), + .result = 1 << 2, + }, +}; + +KUNIT_ARRAY_PARAM(reciprocal_div, reciprocal_div_cases, NULL); + +static void reciprocal_div_test(struct kunit *test) +{ + const struct u32_test_case *test_param = test->param_value; + struct reciprocal_value rv = reciprocal_value(test_param->b); + + KUNIT_EXPECT_EQ_MSG(test, test_param->result, + reciprocal_divide(test_param->a, rv), + "reciprocal_divide(%u, %u)", + test_param->a, test_param->b); +} + +static void reciprocal_scale_test(struct kunit *test) +{ + KUNIT_EXPECT_EQ(test, reciprocal_scale(0u, 100), 0u); + KUNIT_EXPECT_EQ(test, reciprocal_scale(1u, 100), 0u); + KUNIT_EXPECT_EQ(test, reciprocal_scale(1u << 4, 1 << 28), 1u); + KUNIT_EXPECT_EQ(test, reciprocal_scale(1u << 16, 1 << 28), 1u << 12); + KUNIT_EXPECT_EQ(test, reciprocal_scale(~0u, 1 << 28), (1u << 28) - 1); +} + +static struct kunit_case math_test_cases[] = { + KUNIT_CASE(abs_test), + KUNIT_CASE(int_sqrt_test), + KUNIT_CASE(round_up_test), + KUNIT_CASE(round_down_test), + KUNIT_CASE(roundup_test), + KUNIT_CASE(rounddown_test), + KUNIT_CASE(div_round_up_test), + KUNIT_CASE(div_round_closest_test), + KUNIT_CASE_PARAM(gcd_test, gcd_gen_params), + KUNIT_CASE_PARAM(lcm_test, lcm_gen_params), + KUNIT_CASE_PARAM(reciprocal_div_test, reciprocal_div_gen_params), + KUNIT_CASE(reciprocal_scale_test), + {} +}; + +static struct kunit_suite math_test_suite = { + .name = "lib-math", + .test_cases = math_test_cases, +}; + +kunit_test_suites(&math_test_suite); + +MODULE_LICENSE("GPL v2"); base-commit: 7e25f40eab52c57ff6772d27d2aef3640a3237d7 -- 2.31.1.368.gbe11c130af-goog

1 year

5
5
0 0

[PATCH] Documentation: kunit: Clarify test filter format

by Brendan Jackman

It seems obvious once you know, but at first I didn't realise that the suite name is part of this format. Document it and add example. Signed-off-by: Brendan Jackman <jackmanb(a)google.com> --- Documentation/dev-tools/kunit/run_wrapper.rst | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/dev-tools/kunit/run_wrapper.rst b/Documentation/dev-tools/kunit/run_wrapper.rst index 19ddf5e07013..e75a5fc05814 100644 --- a/Documentation/dev-tools/kunit/run_wrapper.rst +++ b/Documentation/dev-tools/kunit/run_wrapper.rst @@ -156,13 +156,20 @@ Filtering tests =============== By passing a bash style glob filter to the ``exec`` or ``run`` -commands, we can run a subset of the tests built into a kernel . For +commands, we can run a subset of the tests built into a kernel, +identified by a string like ``$suite_name.$test_name``. For example: if we only want to run KUnit resource tests, use: .. code-block:: ./tools/testing/kunit/kunit.py run 'kunit-resource*' +Or to run just one specific test from that suite: + +.. code-block:: + + ./tools/testing/kunit/kunit.py run 'kunit-resource-test.kunit_resource_test_init_resources' + This uses the standard glob format with wildcard characters. .. _kunit-on-qemu: -- 2.44.0.396.g6e790dbe36-goog

1 year

3
3
0 0

[PATCH] Build guest_memfd_test also on arm64.

by Itaru Kitayama

--- on arm64 KVM_CAP_GUEST_MEMDF capability is not enabled, but guest_memfd_test can build on arm64, let's build it on arm64 as well. Signed-off-by: Itaru Kitayama <itaru.kitayama(a)fujitsu.com> --- tools/testing/selftests/kvm/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index 492e937fab00..8a4f8afb81ca 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -158,6 +158,7 @@ TEST_GEN_PROGS_aarch64 += access_tracking_perf_test TEST_GEN_PROGS_aarch64 += demand_paging_test TEST_GEN_PROGS_aarch64 += dirty_log_test TEST_GEN_PROGS_aarch64 += dirty_log_perf_test +TEST_GEN_PROGS_aarch64 += guest_memfd_test TEST_GEN_PROGS_aarch64 += guest_print_test TEST_GEN_PROGS_aarch64 += get-reg-list TEST_GEN_PROGS_aarch64 += kvm_create_max_vcpus --- base-commit: 39133352cbed6626956d38ed72012f49b0421e7b change-id: 20240222-memfd-7285f9564c1e Best regards, -- Itaru Kitayama <itaru.kitayama(a)linux.dev>

1 year

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror March 2024