Linux-kselftest-mirror October 2023

linux-kselftest-mirror@lists.linaro.org

172 participants
242 discussions

[PATCH RESEND] kunit: debugfs: Fix unchecked dereference in debugfs_print_results()

by Richard Fitzgerald

Move the call to kunit_suite_has_succeeded() after the check that the kunit_suite pointer is valid. This was found by smatch: lib/kunit/debugfs.c:66 debugfs_print_results() warn: variable dereferenced before check 'suite' (see line 63) Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Fixes: 38289a26e1b8 ("kunit: fix debugfs code to use enum kunit_status, not bool") --- lib/kunit/debugfs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/kunit/debugfs.c b/lib/kunit/debugfs.c index 9d167adfa746..382706dfb47d 100644 --- a/lib/kunit/debugfs.c +++ b/lib/kunit/debugfs.c @@ -60,12 +60,14 @@ static void debugfs_print_result(struct seq_file *seq, struct string_stream *log static int debugfs_print_results(struct seq_file *seq, void *v) { struct kunit_suite *suite = (struct kunit_suite *)seq->private; - enum kunit_status success = kunit_suite_has_succeeded(suite); + enum kunit_status success; struct kunit_case *test_case; if (!suite) return 0; + success = kunit_suite_has_succeeded(suite); + /* Print KTAP header so the debugfs log can be parsed as valid KTAP. */ seq_puts(seq, "KTAP version 1\n"); seq_puts(seq, "1..1\n"); -- 2.30.2

2 years, 1 month

[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

2 years, 1 month

[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

2 years, 1 month

[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

2 years, 1 month

[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

2 years, 1 month

[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

2 years, 1 month

[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

2 years, 1 month

selftests: gpio: crash on arm64

by Naresh Kamboju

Following kernel warnings and crash notices on arm64 Rpi4 device while running selftests: gpio on Linux mainline 6.3.0-rc1 kernel and Linux next. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Please refer to test log links for detailed test plan and kernel crash logs. It is reproducible on arm64 juno-r2, Rpi4 and Qualcomm dragonboard 410c and qemu-arm64. Test log: ----------- kselftest: Running tests in gpio TAP version 13 1..2 # selftests: gpio: gpio-mockup.sh # 1. Module load tests [ 61.176149] ============================================================================= [ 61.176802] [ 61.176807] ====================================================== [ 61.176809] WARNING: possible circular locking dependency detected [ 61.176811] 6.3.0-rc1-next-20230307 #1 Not tainted [ 61.176814] ------------------------------------------------------ [ 61.176816] modprobe/510 is trying to acquire lock: [ 61.176818] ffff80000b2284e8 (console_owner){..-.}-{0:0}, at: console_flush_all (kernel/printk/printk.c:2879 kernel/printk/printk.c:2942) [ 61.176846] [ 61.176846] but task is already holding lock: [ 61.176848] ffff000040000698 (&n->list_lock){-.-.}-{2:2}, at: get_partial_node.part.0 (mm/slub.c:2271) [ 61.176861] [ 61.176861] which lock already depends on the new lock. [ 61.176861] [ 61.176863] [ 61.176863] the existing dependency chain (in reverse order) is: [ 61.176864] [ 61.176864] -> #2 (&n->list_lock){-.-.}-{2:2}: [ 61.176871] lock_acquire (kernel/locking/lockdep.c:5673) [ 61.176879] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 61.176885] get_partial_node.part.0 (mm/slub.c:2271) [ 61.176890] ___slab_alloc (mm/slub.c:2268 mm/slub.c:2386 mm/slub.c:3188) [ 61.176894] __slab_alloc.constprop.0 (mm/slub.c:3292) [ 61.176899] __kmem_cache_alloc_node (mm/slub.c:3345 mm/slub.c:3442 mm/slub.c:3491) [ 61.176903] __kmalloc (mm/slab_common.c:968 mm/slab_common.c:980) [ 61.176908] tty_buffer_alloc (drivers/tty/tty_buffer.c:182) [ 61.176914] __tty_buffer_request_room (drivers/tty/tty_buffer.c:279) [ 61.176919] __tty_insert_flip_char (drivers/tty/tty_buffer.c:398) [ 61.176924] uart_insert_char (drivers/tty/serial/serial_core.c:3341) [ 61.176929] pl011_fifo_to_tty.isra.0 (drivers/tty/serial/amba-pl011.c:314) [ 61.176934] pl011_int (include/linux/spinlock.h:390 drivers/tty/serial/amba-pl011.c:1396 drivers/tty/serial/amba-pl011.c:1571) [ 61.176937] __handle_irq_event_percpu (kernel/irq/handle.c:158) [ 61.176941] handle_irq_event (kernel/irq/handle.c:193 kernel/irq/handle.c:210) [ 61.176944] handle_fasteoi_irq (kernel/irq/chip.c:716) [ 61.176950] generic_handle_domain_irq (kernel/irq/irqdesc.c:652 kernel/irq/irqdesc.c:707) [ 61.176953] gic_handle_irq (arch/arm64/include/asm/io.h:75 include/asm-generic/io.h:335 drivers/irqchip/irq-gic.c:344) [ 61.176958] call_on_irq_stack (arch/arm64/kernel/entry.S:905) [ 61.176962] do_interrupt_handler (arch/arm64/kernel/entry-common.c:274) [ 61.176968] el1_interrupt (arch/arm64/kernel/entry-common.c:472 arch/arm64/kernel/entry-common.c:486) [ 61.176971] el1h_64_irq_handler (arch/arm64/kernel/entry-common.c:492) [ 61.176975] el1h_64_irq (arch/arm64/kernel/entry.S:587) [ 61.176978] __kmem_cache_alloc_node (mm/slub.c:3490) [ 61.176983] kmalloc_trace (mm/slab_common.c:1064 (discriminator 4)) [ 61.176986] inet6_dump_fib (net/ipv6/ip6_fib.c:657) [ 61.176991] rtnl_dump_all (net/core/rtnetlink.c:3964) [ 61.176997] netlink_dump (net/netlink/af_netlink.c:2296) [ 61.177004] netlink_recvmsg (net/netlink/af_netlink.c:2024) [ 61.177009] ____sys_recvmsg (net/socket.c:1015 net/socket.c:1036 net/socket.c:2723) [ 61.177014] ___sys_recvmsg (net/socket.c:2765) [ 61.177019] __sys_recvmsg (include/linux/file.h:31 net/socket.c:2797) [ 61.177025] __arm64_sys_recvmsg (net/socket.c:2802) [ 61.177030] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:57) [ 61.177037] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:149) [ 61.177043] do_el0_svc (arch/arm64/kernel/syscall.c:194) [ 61.177049] el0_svc (arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/entry-common.c:133 arch/arm64/kernel/entry-common.c:142 arch/arm64/kernel/entry-common.c:638) [ 61.177052] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:656) [ 61.177055] el0t_64_sync (arch/arm64/kernel/entry.S:591) [ 61.177058] [ 61.177058] -> #1 (&port_lock_key){-.-.}-{2:2}: [ 61.177065] lock_acquire (kernel/locking/lockdep.c:5673) [ 61.177071] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 61.177074] serial8250_console_write (drivers/tty/serial/8250/8250_port.c:3394) [ 61.177082] univ8250_console_write (drivers/tty/serial/8250/8250_core.c:585) [ 61.177087] console_flush_all (kernel/printk/printk.c:2888 kernel/printk/printk.c:2942) [ 61.177093] console_unlock.part.0 (kernel/printk/printk.c:3017) [ 61.177098] vprintk_emit (kernel/printk/printk.c:2317) [ 61.177104] vprintk_default (kernel/printk/printk.c:2328) [ 61.177110] vprintk (kernel/printk/printk_safe.c:50) [ 61.177116] _printk (kernel/printk/printk.c:2341) [ 61.177121] register_console (kernel/printk/printk.c:3468) [ 61.177126] uart_add_one_port (drivers/tty/serial/serial_core.c:2579 drivers/tty/serial/serial_core.c:3100) [ 61.177130] serial8250_register_8250_port (drivers/tty/serial/8250/8250_core.c:1093) [ 61.177135] bcm2835aux_serial_probe (drivers/tty/serial/8250/8250_bcm2835aux.c:184) [ 61.177141] platform_probe (drivers/base/platform.c:1405) [ 61.177148] really_probe (drivers/base/dd.c:552 drivers/base/dd.c:631) [ 61.177152] __driver_probe_device (drivers/base/dd.c:768) [ 61.177157] driver_probe_device (drivers/base/dd.c:798) [ 61.177161] __driver_attach (drivers/base/dd.c:1185) [ 61.177166] bus_for_each_dev (drivers/base/bus.c:368) [ 61.177170] driver_attach (drivers/base/dd.c:1202) [ 61.177173] bus_add_driver (drivers/base/bus.c:673) [ 61.177177] driver_register (drivers/base/driver.c:246) [ 61.177182] __platform_driver_register (drivers/base/platform.c:868) [ 61.177188] bcm2835aux_serial_driver_init (drivers/tty/serial/8250/8250_bcm2835aux.c:233) [ 61.177195] do_one_initcall (init/main.c:1306) [ 61.177199] kernel_init_freeable (init/main.c:1378 init/main.c:1395 init/main.c:1414 init/main.c:1634) [ 61.177207] kernel_init (init/main.c:1524) [ 61.177212] ret_from_fork (arch/arm64/kernel/entry.S:871) [ 61.177216] [ 61.177216] -> #0 (console_owner){..-.}-{0:0}: [ 61.177222] __lock_acquire (kernel/locking/lockdep.c:3099 kernel/locking/lockdep.c:3217 kernel/locking/lockdep.c:3832 kernel/locking/lockdep.c:5056) [ 61.177228] lock_acquire.part.0 (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5671) [ 61.177233] lock_acquire (kernel/locking/lockdep.c:5673) [ 61.177238] console_flush_all (kernel/printk/printk.c:2883 kernel/printk/printk.c:2942) [ 61.177244] console_unlock.part.0 (kernel/printk/printk.c:3017) [ 61.177250] vprintk_emit (kernel/printk/printk.c:2317) [ 61.177255] vprintk_default (kernel/printk/printk.c:2328) [ 61.177261] vprintk (kernel/printk/printk_safe.c:50) [ 61.177267] _printk (kernel/printk/printk.c:2341) [ 61.177271] slab_bug (mm/slub.c:892) [ 61.177274] check_bytes_and_report (mm/slub.c:1054) [ 61.177279] check_object (mm/slub.c:1196 (discriminator 2)) [ 61.177283] alloc_debug_processing (mm/slub.c:1415 mm/slub.c:1425) [ 61.177287] get_partial_node.part.0 (mm/slub.c:2146 mm/slub.c:2279) [ 61.177291] ___slab_alloc (mm/slub.c:2268 mm/slub.c:2386 mm/slub.c:3188) [ 61.177295] __slab_alloc.constprop.0 (mm/slub.c:3292) [ 61.177300] __kmem_cache_alloc_node (mm/slub.c:3345 mm/slub.c:3442 mm/slub.c:3491) [ 61.177304] kmalloc_trace (mm/slab_common.c:1064 (discriminator 4)) [ 61.177308] device_add (drivers/base/core.c:3436 drivers/base/core.c:3486) [ 61.177311] platform_device_add (drivers/base/platform.c:717) [ 61.177317] platform_device_register_full (drivers/base/platform.c:844) [ 61.177323] gpio_mockup_register_chip+0x1ec/0x2b8 gpio_mockup [ 61.177342] gpio_mockup_init+0xf0/0xd40 gpio_mockup [ 61.177352] do_one_initcall (init/main.c:1306) [ 61.177356] do_init_module (kernel/module/main.c:2457) [ 61.177363] load_module (kernel/module/main.c:2859) [ 61.177369] __do_sys_finit_module (kernel/module/main.c:2961) [ 61.177375] __arm64_sys_finit_module (kernel/module/main.c:2928) [ 61.177381] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:57) [ 61.177387] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:149) [ 61.177393] do_el0_svc (arch/arm64/kernel/syscall.c:194) [ 61.177398] el0_svc (arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/entry-common.c:133 arch/arm64/kernel/entry-common.c:142 arch/arm64/kernel/entry-common.c:638) [ 61.177402] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:656) [ 61.177405] el0t_64_sync (arch/arm64/kernel/entry.S:591) [ 61.177408] [ 61.177408] other info that might help us debug this: [ 61.177408] [ 61.177410] Chain exists of: [ 61.177410] console_owner --> &port_lock_key --> &n->list_lock [ 61.177410] [ 61.177417] Possible unsafe locking scenario: [ 61.177417] [ 61.177418] CPU0 CPU1 [ 61.177419] ---- ---- [ 61.177420] lock(&n->list_lock); [ 61.177423] lock(&port_lock_key); [ 61.177426] lock(&n->list_lock); [ 61.177429] lock(console_owner); [ 61.177432] [ 61.177432] *** DEADLOCK *** [ 61.177432] [ 61.177434] 3 locks held by modprobe/510: [ 61.177436] #0: ffff000040000698 (&n->list_lock){-.-.}-{2:2}, at: get_partial_node.part.0 (mm/slub.c:2271) [ 61.177448] #1: ffff80000b227f18 (console_lock){+.+.}-{0:0}, at: vprintk_emit (kernel/printk/printk.c:1936 kernel/printk/printk.c:2315) [ 61.177460] #2: ffff80000b228388 (console_srcu){....}-{0:0}, at: console_flush_all (include/linux/srcu.h:200 kernel/printk/printk.c:290 kernel/printk/printk.c:2934) [ 61.177471] [ 61.177471] stack backtrace: [ 61.177474] CPU: 3 PID: 510 Comm: modprobe Not tainted 6.3.0-rc1-next-20230307 #1 [ 61.177479] Hardware name: Raspberry Pi 4 Model B (DT) [ 61.177482] Call trace: [ 61.177483] dump_backtrace (arch/arm64/kernel/stacktrace.c:160) [ 61.177487] show_stack (arch/arm64/kernel/stacktrace.c:167) [ 61.177490] dump_stack_lvl (lib/dump_stack.c:107) [ 61.177498] dump_stack (lib/dump_stack.c:114) [ 61.177504] print_circular_bug (kernel/locking/lockdep.c:2057) [ 61.177509] check_noncircular (kernel/locking/lockdep.c:2181) [ 61.177514] __lock_acquire (kernel/locking/lockdep.c:3099 kernel/locking/lockdep.c:3217 kernel/locking/lockdep.c:3832 kernel/locking/lockdep.c:5056) [ 61.177520] lock_acquire.part.0 (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5671) [ 61.177525] lock_acquire (kernel/locking/lockdep.c:5673) [ 61.177530] console_flush_all (kernel/printk/printk.c:2883 kernel/printk/printk.c:2942) [ 61.177536] console_unlock.part.0 (kernel/printk/printk.c:3017) [ 61.177542] vprintk_emit (kernel/printk/printk.c:2317) [ 61.177547] vprintk_default (kernel/printk/printk.c:2328) [ 61.177553] vprintk (kernel/printk/printk_safe.c:50) [ 61.177559] _printk (kernel/printk/printk.c:2341) [ 61.177564] slab_bug (mm/slub.c:892) [ 61.177567] check_bytes_and_report (mm/slub.c:1054) [ 61.177571] check_object (mm/slub.c:1196 (discriminator 2)) [ 61.177575] alloc_debug_processing (mm/slub.c:1415 mm/slub.c:1425) [ 61.177579] get_partial_node.part.0 (mm/slub.c:2146 mm/slub.c:2279) [ 61.177583] ___slab_alloc (mm/slub.c:2268 mm/slub.c:2386 mm/slub.c:3188) [ 61.177587] __slab_alloc.constprop.0 (mm/slub.c:3292) [ 61.177592] __kmem_cache_alloc_node (mm/slub.c:3345 mm/slub.c:3442 mm/slub.c:3491) [ 61.177596] kmalloc_trace (mm/slab_common.c:1064 (discriminator 4)) [ 61.177600] device_add (drivers/base/core.c:3436 drivers/base/core.c:3486) [ 61.177603] platform_device_add (drivers/base/platform.c:717) [ 61.177609] platform_device_register_full (drivers/base/platform.c:844) [ 61.177615] gpio_mockup_register_chip+0x1ec/0x2b8 gpio_mockup [ 61.177625] gpio_mockup_init+0xf0/0xd40 gpio_mockup [ 61.177634] do_one_initcall (init/main.c:1306) [ 61.177638] do_init_module (kernel/module/main.c:2457) [ 61.177644] load_module (kernel/module/main.c:2859) [ 61.177650] __do_sys_finit_module (kernel/module/main.c:2961) [ 61.177656] __arm64_sys_finit_module (kernel/module/main.c:2928) [ 61.177662] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:57) [ 61.177668] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:149) [ 61.177674] do_el0_svc (arch/arm64/kernel/syscall.c:194) [ 61.177680] el0_svc (arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/entry-common.c:133 arch/arm64/kernel/entry-common.c:142 arch/arm64/kernel/entry-common.c:638) [ 61.177683] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:656) [ 61.177686] el0t_64_sync (arch/arm64/kernel/entry.S:591) [ 62.011685] BUG kmalloc-512 (Not tainted): Poison overwritten [ 62.017513] ----------------------------------------------------------------------------- [ 62.017513] [ 62.027300] 0xffff00004ecb7a38-0xffff00004ecb7a47 @offset=31288. First byte 0x6a instead of 0x6b [ 62.036210] Allocated in swnode_register+0x40/0x218 age=808 cpu=3 pid=386 [ 62.043101] __kmem_cache_alloc_node (mm/slub.c:3345 mm/slub.c:3442 mm/slub.c:3491) [ 62.047784] kmalloc_trace (mm/slab_common.c:1064 (discriminator 4)) [ 62.051406] swnode_register (drivers/base/swnode.c:776) [ 62.055293] fwnode_create_software_node (drivers/base/swnode.c:934 (discriminator 4)) [ 62.060238] gpio_mockup_register_chip+0x1c4/0x2b8 gpio_mockup [ 62.066337] gpio_mockup_init+0xf0/0xd40 gpio_mockup [ 62.071551] do_one_initcall (init/main.c:1306) [ 62.075437] do_init_module (kernel/module/main.c:2457) [ 62.079238] load_module (kernel/module/main.c:2859) [ 62.083037] __do_sys_finit_module (kernel/module/main.c:2961) [ 62.087455] __arm64_sys_finit_module (kernel/module/main.c:2928) [ 62.092048] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:57) [ 62.095848] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:149) [ 62.100793] do_el0_svc (arch/arm64/kernel/syscall.c:194) [ 62.104151] el0_svc (arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/entry-common.c:133 arch/arm64/kernel/entry-common.c:142 arch/arm64/kernel/entry-common.c:638) [ 62.107244] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:656) [ 62.111570] Freed in software_node_release+0xdc/0x108 age=632 cpu=0 pid=428 [ 62.118633] __kmem_cache_free (mm/slub.c:3732 mm/slub.c:3788 mm/slub.c:3800) [ 62.122784] kfree (mm/slab_common.c:1020) [ 62.125788] software_node_release (drivers/base/swnode.c:761) [ 62.130204] kobject_put (lib/kobject.c:685 lib/kobject.c:712 include/linux/kref.h:65 lib/kobject.c:729) [ 62.133739] software_node_notify_remove (drivers/base/swnode.c:1093) [ 62.138597] device_del (drivers/base/core.c:2265 drivers/base/core.c:3778) [ 62.142134] platform_device_del.part.0 (drivers/base/platform.c:753) [ 62.146903] platform_device_unregister (drivers/base/platform.c:551 drivers/base/platform.c:794) [ 62.151672] gpio_mockup_exit+0x54/0x280 gpio_mockup [ 62.156888] __arm64_sys_delete_module (kernel/module/main.c:756 kernel/module/main.c:698 kernel/module/main.c:698) [ 62.161745] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:57) [ 62.165545] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:149) [ 62.170490] do_el0_svc (arch/arm64/kernel/syscall.c:194) [ 62.173850] el0_svc (arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/entry-common.c:133 arch/arm64/kernel/entry-common.c:142 arch/arm64/kernel/entry-common.c:638) [ 62.176941] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:656) [ 62.181267] el0t_64_sync (arch/arm64/kernel/entry.S:591) [ 62.184975] Slab 0xfffffc00013b2c00 objects=21 used=7 fp=0xffff00004ecb7400 flags=0x7fffc0000010200(slab|head|node=0|zone=1|lastcpupid=0xffff) [ 62.197943] Object 0xffff00004ecb7a00 @offset=31232 fp=0xffff00004ecb7400 [ 62.197943] [ 62.206325] Redzone ffff00004ecb7800: ... [ 63.089597] CPU: 3 PID: 510 Comm: modprobe Not tainted 6.3.0-rc1-next-20230307 #1 [ 63.097186] Hardware name: Raspberry Pi 4 Model B (DT) [ 63.102392] Call trace: [ 63.104865] dump_backtrace (arch/arm64/kernel/stacktrace.c:160) [ 63.108665] show_stack (arch/arm64/kernel/stacktrace.c:167) [ 63.112021] dump_stack_lvl (lib/dump_stack.c:107) [ 63.115734] dump_stack (lib/dump_stack.c:114) [ 63.119093] print_trailer (mm/slub.c:953) [ 63.122892] check_bytes_and_report (mm/slub.c:1058) [ 63.127395] check_object (mm/slub.c:1196 (discriminator 2)) [ 63.131104] alloc_debug_processing (mm/slub.c:1415 mm/slub.c:1425) [ 63.135606] get_partial_node.part.0 (mm/slub.c:2146 mm/slub.c:2279) [ 63.140286] ___slab_alloc (mm/slub.c:2268 mm/slub.c:2386 mm/slub.c:3188) [ 63.144084] __slab_alloc.constprop.0 (mm/slub.c:3292) [ 63.148674] __kmem_cache_alloc_node (mm/slub.c:3345 mm/slub.c:3442 mm/slub.c:3491) [ 63.153354] kmalloc_trace (mm/slab_common.c:1064 (discriminator 4)) [ 63.156974] device_add (drivers/base/core.c:3436 drivers/base/core.c:3486) [ 63.160508] platform_device_add (drivers/base/platform.c:717) [ 63.164837] platform_device_register_full (drivers/base/platform.c:844) [ 63.169959] gpio_mockup_register_chip+0x1ec/0x2b8 gpio_mockup [ 63.176057] gpio_mockup_init+0xf0/0xd40 gpio_mockup [ 63.181269] do_one_initcall (init/main.c:1306) [ 63.185155] do_init_module (kernel/module/main.c:2457) [ 63.188956] load_module (kernel/module/main.c:2859) [ 63.192755] __do_sys_finit_module (kernel/module/main.c:2961) [ 63.197171] __arm64_sys_finit_module (kernel/module/main.c:2928) [ 63.201765] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:57) [ 63.205565] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:149) [ 63.210510] do_el0_svc (arch/arm64/kernel/syscall.c:194) [ 63.213869] el0_svc (arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/entry-common.c:133 arch/arm64/kernel/entry-common.c:142 arch/arm64/kernel/entry-common.c:638) [ 63.216961] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:656) [ 63.221287] el0t_64_sync (arch/arm64/kernel/entry.S:591) [ 63.224998] FIX kmalloc-512: Restoring Poison 0xffff00004ecb7a38-0xffff00004ecb7a47=0x6b [ 63.233202] FIX kmalloc-512: Marking all objects used [ 63.399213] ============================================================================= links to the crash: - https://lkft.validation.linaro.org/scheduler/job/6224830#L1291 - https://lkft.validation.linaro.org/scheduler/job/6224742#L1202 - https://lkft.validation.linaro.org/scheduler/job/6224784#L3415 - https://lkft.validation.linaro.org/scheduler/job/6224810#L2029 metadata: git_ref: master git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git_sha: 709c6adf19dc558e44ab5c01659b09a16a2d3c82 git_describe: next-20230307 kernel_version: 6.3.0-rc1 kernel-config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2MfXESbRAbSUj9oic6d8… build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/798095907 artifact-location: https://storage.tuxsuite.com/public/linaro/lkft/builds/2MfXESbRAbSUj9oic6d8… toolchain: gcc-11 -- Linaro LKFT https://lkft.linaro.org

2 years, 1 month

[PATCH V10 0/7] amd-pstate preferred core

by Meng Li

Hi all: The core frequency is subjected to the process variation in semiconductors. Not all cores are able to reach the maximum frequency respecting the infrastructure limits. Consequently, AMD has redefined the concept of maximum frequency of a part. This means that a fraction of cores can reach maximum frequency. To find the best process scheduling policy for a given scenario, OS needs to know the core ordering informed by the platform through highest performance capability register of the CPPC interface. Earlier implementations of amd-pstate preferred core only support a static core ranking and targeted performance. Now it has the ability to dynamically change the preferred core based on the workload and platform conditions and accounting for thermals and aging. Amd-pstate driver utilizes the functions and data structures provided by the ITMT architecture to enable the scheduler to favor scheduling on cores which can be get a higher frequency with lower voltage. We call it amd-pstate preferred core. Here sched_set_itmt_core_prio() is called to set priorities and sched_set_itmt_support() is called to enable ITMT feature. Amd-pstate driver uses the highest performance value to indicate the priority of CPU. The higher value has a higher priority. Amd-pstate driver will provide an initial core ordering at boot time. It relies on the CPPC interface to communicate the core ranking to the operating system and scheduler to make sure that OS is choosing the cores with highest performance firstly for scheduling the process. When amd-pstate driver receives a message with the highest performance change, it will update the core ranking. Changes from V9->V10: - cpufreq: amd-pstate: - - add judgement for highest_perf. When it is less than 255, the preferred core feature is enabled. And it will set the priority. - - deleset "static u32 max_highest_perf" etc, because amd p-state perferred coe does not require specail process for hotpulg. Changes form V8->V9: - all: - - pick up Tested-By flag added by Oleksandr. - cpufreq: amd-pstate: - - pick up Review-By flag added by Wyes. - - ignore modification of bug. - - add a attribute of prefcore_ranking. - - modify data type conversion from u32 to int. - Documentation: amd-pstate: - - pick up Review-By flag added by Wyes. Changes form V7->V8: - all: - - pick up Review-By flag added by Mario and Ray. - cpufreq: amd-pstate: - - use hw_prefcore embeds into cpudata structure. - - delete preferred core init from cpu online/off. Changes form V6->V7: - x86: - - Modify kconfig about X86_AMD_PSTATE. - cpufreq: amd-pstate: - - modify incorrect comments about scheduler_work(). - - convert highest_perf data type. - - modify preferred core init when cpu init and online. - acpi: cppc: - - modify link of CPPC highest performance. - cpufreq: - - modify link of CPPC highest performance changed. Changes form V5->V6: - cpufreq: amd-pstate: - - modify the wrong tag order. - - modify warning about hw_prefcore sysfs attribute. - - delete duplicate comments. - - modify the variable name cppc_highest_perf to prefcore_ranking. - - modify judgment conditions for setting highest_perf. - - modify sysfs attribute for CPPC highest perf to pr_debug message. - Documentation: amd-pstate: - - modify warning: title underline too short. Changes form V4->V5: - cpufreq: amd-pstate: - - modify sysfs attribute for CPPC highest perf. - - modify warning about comments - - rebase linux-next - cpufreq: - - Moidfy warning about function declarations. - Documentation: amd-pstate: - - align with ``amd-pstat`` Changes form V3->V4: - Documentation: amd-pstate: - - Modify inappropriate descriptions. Changes form V2->V3: - x86: - - Modify kconfig and description. - cpufreq: amd-pstate: - - Add Co-developed-by tag in commit message. - cpufreq: - - Modify commit message. - Documentation: amd-pstate: - - Modify inappropriate descriptions. Changes form V1->V2: - acpi: cppc: - - Add reference link. - cpufreq: - - Moidfy link error. - cpufreq: amd-pstate: - - Init the priorities of all online CPUs - - Use a single variable to represent the status of preferred core. - Documentation: - - Default enabled preferred core. - Documentation: amd-pstate: - - Modify inappropriate descriptions. - - Default enabled preferred core. - - Use a single variable to represent the status of preferred core. Meng Li (7): x86: Drop CPU_SUP_INTEL from SCHED_MC_PRIO for the expansion. acpi: cppc: Add get the highest performance cppc control cpufreq: amd-pstate: Enable amd-pstate preferred core supporting. cpufreq: Add a notification message that the highest perf has changed cpufreq: amd-pstate: Update amd-pstate preferred core ranking dynamically Documentation: amd-pstate: introduce amd-pstate preferred core Documentation: introduce amd-pstate preferrd core mode kernel command line options .../admin-guide/kernel-parameters.txt | 5 + Documentation/admin-guide/pm/amd-pstate.rst | 59 +++++- arch/x86/Kconfig | 5 +- drivers/acpi/cppc_acpi.c | 13 ++ drivers/acpi/processor_driver.c | 6 + drivers/cpufreq/amd-pstate.c | 187 ++++++++++++++++-- drivers/cpufreq/cpufreq.c | 13 ++ include/acpi/cppc_acpi.h | 5 + include/linux/amd-pstate.h | 10 + include/linux/cpufreq.h | 5 + 10 files changed, 288 insertions(+), 20 deletions(-) -- 2.34.1

2 years, 1 month

[PATCH v2 0/4] cgroup/cpuset: Improve CPU isolation in isolated partitions

by Waiman Long

v2: - Add 2 read-only workqueue sysfs files to expose the user requested cpumask as well as the isolated CPUs to be excluded from wq_unbound_cpumask. - Ensure that caller of the new workqueue_unbound_exclude_cpumask() hold cpus_read_lock. - Update the cpuset code to make sure the cpus_read_lock is held whenever workqueue_unbound_exclude_cpumask() may be called. Isolated cpuset partition can currently be created to contain an exclusive set of CPUs not used in other cgroups and with load balancing disabled to reduce interference from the scheduler. The main purpose of this isolated partition type is to dynamically emulate what can be done via the "isolcpus" boot command line option, specifically the default domain flag. One effect of the "isolcpus" option is to remove the isolated CPUs from the cpumasks of unbound workqueues since running work functions in an isolated CPU can be a major source of interference. Changing the unbound workqueue cpumasks can be done at run time by writing an appropriate cpumask without the isolated CPUs to /sys/devices/virtual/workqueue/cpumask. So one can set up an isolated cpuset partition and then write to the cpumask sysfs file to achieve similar level of CPU isolation. However, this manual process can be error prone. This patch series implements automatic exclusion of isolated CPUs from unbound workqueue cpumasks when an isolated cpuset partition is created and then adds those CPUs back when the isolated partition is destroyed. There are also other places in the kernel that look at the HK_FLAG_DOMAIN cpumask or other HK_FLAG_* cpumasks and exclude the isolated CPUs from certain actions to further reduce interference. CPUs in an isolated cpuset partition will not be able to avoid those interferences yet. That may change in the future as the need arises. Waiman Long (4): workqueue: Add workqueue_unbound_exclude_cpumask() to exclude CPUs from wq_unbound_cpumask selftests/cgroup: Minor code cleanup and reorganization of test_cpuset_prs.sh cgroup/cpuset: Keep track of CPUs in isolated partitions cgroup/cpuset: Take isolated CPUs out of workqueue unbound cpumask Documentation/admin-guide/cgroup-v2.rst | 10 +- include/linux/workqueue.h | 2 +- kernel/cgroup/cpuset.c | 286 +++++++++++++----- kernel/workqueue.c | 91 +++++- .../selftests/cgroup/test_cpuset_prs.sh | 216 ++++++++----- 5 files changed, 438 insertions(+), 167 deletions(-) -- 2.39.3

2 years, 1 month

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror October 2023