October 2024 - Linux-kselftest-mirror

[PATCH v5 v6.11 v5.15 v5.4 v4.19 1/1] selftests: breakpoints: use remaining time to check if suspend succeed

by Yifei Liu

step_after_suspend_test fails with device busy error while writing to /sys/power/state to start suspend. The test believes it failed to enter suspend state with $ sudo ./step_after_suspend_test TAP version 13 Bail out! Failed to enter Suspend state However, in the kernel message, I indeed see the system get suspended and then wake up later. [611172.033108] PM: suspend entry (s2idle) [611172.044940] Filesystems sync: 0.006 seconds [611172.052254] Freezing user space processes [611172.059319] Freezing user space processes completed (elapsed 0.001 seconds) [611172.067920] OOM killer disabled. [611172.072465] Freezing remaining freezable tasks [611172.080332] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [611172.089724] printk: Suspending console(s) (use no_console_suspend to debug) [611172.117126] serial 00:03: disabled some other hardware get reconnected [611203.136277] OOM killer enabled. [611203.140637] Restarting tasks ... [611203.141135] usb 1-8.1: USB disconnect, device number 7 [611203.141755] done. [611203.155268] random: crng reseeded on system resumption [611203.162059] PM: suspend exit After investigation, I noticed that for the code block if (write(power_state_fd, "mem", strlen("mem")) != strlen("mem")) ksft_exit_fail_msg("Failed to enter Suspend state\n"); The write will return -1 and errno is set to 16 (device busy). It should be caused by the write function is not successfully returned before the system suspend and the return value get messed when waking up. As a result, It may be better to check the time passed of those few instructions to determine whether the suspend is executed correctly for it is pretty hard to execute those few lines for 5 seconds. The timer to wake up the system is set to expire after 5 seconds and no re-arm. If the timer remaining time is 0 second and 0 nano secomd, it means the timer expired and wake the system up. Otherwise, the system could be considered to enter the suspend state failed if there is any remaining time. After appling this patch, the test would not fail for it believes the system does not go to suspend by mistake. It now could continue to the rest part of the test after suspend. Fixes: bfd092b8c272 ("selftests: breakpoint: add step_after_suspend_test") Reported-by: Sinadin Shan <sinadin.shan(a)oracle.com> Signed-off-by: Yifei Liu <yifei.l.liu(a)oracle.com> --- v4->v5: Remove the above quotes in the first part. remove the incorrect format which could confuse the git. --- .../testing/selftests/breakpoints/step_after_suspend_test.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/breakpoints/step_after_suspend_test.c b/tools/testing/selftests/breakpoints/step_after_suspend_test.c index dfec31fb9b30d..8d275f03e977f 100644 --- a/tools/testing/selftests/breakpoints/step_after_suspend_test.c +++ b/tools/testing/selftests/breakpoints/step_after_suspend_test.c @@ -152,7 +152,10 @@ void suspend(void) if (err < 0) ksft_exit_fail_msg("timerfd_settime() failed\n"); - if (write(power_state_fd, "mem", strlen("mem")) != strlen("mem")) + system("(echo mem > /sys/power/state) 2> /dev/null"); + + timerfd_gettime(timerfd, &spec); + if (spec.it_value.tv_sec != 0 || spec.it_value.tv_nsec != 0) ksft_exit_fail_msg("Failed to enter Suspend state\n"); close(timerfd); -- 2.46.0

6 months, 2 weeks

2
2
0 0

[PATCH v3] kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3

by Alessandro Zanni

Insert raw strings to prevent Python3 from interpreting string literals as Unicode strings and "\d" as invalid escaped sequence. Fix the warnings: tools/testing/selftests/devices/probe/test_discoverable_devices.py:48: SyntaxWarning: invalid escape sequence '\d' usb_controller_sysfs_dir = "usb[\d]+" tools/testing/selftests/devices/probe/test_discoverable_devices.py: 94: SyntaxWarning: invalid escape sequence '\d' re_usb_version = re.compile("PRODUCT=.*/(\d)/.*") Fixes: dacf1d7a78bf ("kselftest: Add test to verify probe of devices from discoverable buses") Reviewed-by: Nícolas F. R. A. Prado <nfraprado(a)collabora.com> Signed-off-by: Alessandro Zanni <alessandro.zanni87(a)gmail.com> --- Notes: v3: Reduce changelog lines lengthy, add warning messages v2: Imperative mode description, add previous commit tag fix .../selftests/devices/probe/test_discoverable_devices.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/devices/probe/test_discoverable_devices.py b/tools/testing/selftests/devices/probe/test_discoverable_devices.py index d94a74b8a054..d7a2bb91c807 100755 --- a/tools/testing/selftests/devices/probe/test_discoverable_devices.py +++ b/tools/testing/selftests/devices/probe/test_discoverable_devices.py @@ -45,7 +45,7 @@ def find_pci_controller_dirs(): def find_usb_controller_dirs(): - usb_controller_sysfs_dir = "usb[\d]+" + usb_controller_sysfs_dir = r"usb[\d]+" dir_regex = re.compile(usb_controller_sysfs_dir) for d in os.scandir(sysfs_usb_devices): @@ -91,7 +91,7 @@ def get_acpi_uid(sysfs_dev_dir): def get_usb_version(sysfs_dev_dir): - re_usb_version = re.compile("PRODUCT=.*/(\d)/.*") + re_usb_version = re.compile(r"PRODUCT=.*/(\d)/.*") with open(os.path.join(sysfs_dev_dir, "uevent")) as f: return int(re_usb_version.search(f.read()).group(1)) -- 2.43.0

6 months, 2 weeks

2
2
0 0

[PATCH v4 0/3] selftests: livepatch: test livepatching a kprobed function

by Michael Vetter

Thanks to Miroslav, Petr and Marcos for the reviews! V4: Use variable for /sys/kernel/debug. Be consistent with "" around variables. Fix path in commit message to /sys/kernel/debug/kprobes/enabled. V3: Save and restore kprobe state also when test fails, by integrating it into setup_config() and cleanup(). Rename SYSFS variables in a more logical way. Sort test modules in alphabetical order. Rename module description. V2: Save and restore kprobe state. Michael Vetter (3): selftests: livepatch: rename KLP_SYSFS_DIR to SYSFS_KLP_DIR selftests: livepatch: save and restore kprobe state selftests: livepatch: test livepatching a kprobed function tools/testing/selftests/livepatch/Makefile | 3 +- .../testing/selftests/livepatch/functions.sh | 19 ++++-- .../selftests/livepatch/test-kprobe.sh | 62 +++++++++++++++++++ .../selftests/livepatch/test_modules/Makefile | 3 +- .../livepatch/test_modules/test_klp_kprobe.c | 38 ++++++++++++ 5 files changed, 117 insertions(+), 8 deletions(-) create mode 100755 tools/testing/selftests/livepatch/test-kprobe.sh create mode 100644 tools/testing/selftests/livepatch/test_modules/test_klp_kprobe.c -- 2.46.1

6 months, 2 weeks

3
6
0 0

[PATCH slab hotfixes v2 0/2] slub kunit tests fixes for 6.12

by Vlastimil Babka

The SLUB changes for 6.12 included new kunit tests that resulted in noisy warnings, which we normally suppress, and a boot lockup in some configurations in case the kunit tests are built-in. The warnings are addressed in Patch 1. The lockups I couldn't reproduce, but inspecting boot initialization order makes me suspect the test_kfree_rcu() calling kfree_rcu() which is too early before RCU finishes initialization. Moving the exection later was tried but broke tests marking their code as __init so Patch 2 skips the test when the slub kunit tests are built-in. So these are now fixes for 4e1c44b3db79 ("kunit, slub: add test_kfree_rcu() and test_leak_destroy()") The plan is to take the fixes via slab tree for a 6.12 rcX. Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> --- Changes in v2: - patch 2 skips the test when built-in instead of moving kunit execution later - Link to v1: https://lore.kernel.org/r/20240930-b4-slub-kunit-fix-v1-0-32ca9dbbbc11@suse… --- Vlastimil Babka (2): mm, slab: suppress warnings in test_leak_destroy kunit test slub/kunit: skip test_kfree_rcu when the slub kunit test is built-in lib/slub_kunit.c | 18 ++++++++++++------ mm/slab.h | 6 ++++++ mm/slab_common.c | 5 +++-- mm/slub.c | 5 +++-- 4 files changed, 24 insertions(+), 10 deletions(-) --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20240930-b4-slub-kunit-fix-6fba4d1c1742 Best regards, -- Vlastimil Babka <vbabka(a)suse.cz>

6 months, 2 weeks

2
5
0 0

[PATCH RFC v3 0/2] mm: Introduce ADDR_LIMIT_47BIT personality flag

by Charlie Jenkins

Some applications rely on placing data in free bits addresses allocated by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the address returned by mmap to be less than the 48-bit address space, unless the hint address uses more than 47 bits (the 48th bit is reserved for the kernel address space). The riscv architecture needs a way to similarly restrict the virtual address space. On the riscv port of OpenJDK an error is thrown if attempted to run on the 57-bit address space, called sv57 [1]. golang has a comment that sv57 support is not complete, but there are some workarounds to get it to mostly work [2]. These applications work on x86 because x86 does an implicit 47-bit restriction of mmap() address that contain a hint address that is less than 48 bits. Instead of implicitly restricting the address space on riscv (or any current/future architecture), provide a flag to the personality syscall that can be used to ensure an application works in any arbitrary VA space. A similar feature has already been implemented by the personality syscall in ADDR_LIMIT_32BIT. This flag will also allow seemless compatibility between all architectures, so applications like Go and OpenJDK that use bits in a virtual address can request the exact number of bits they need in a generic way. The flag can be checked inside of vm_unmapped_area() so that this flag does not have to be handled individually by each architecture. Link: https://github.com/openjdk/jdk/blob/f080b4bb8a75284db1b6037f8c00ef3b1ef1add… [1] Link: https://github.com/golang/go/blob/9e8ea567c838574a0f14538c0bbbd83c3215aa55/… [2] To: Arnd Bergmann <arnd(a)arndb.de> To: Richard Henderson <richard.henderson(a)linaro.org> To: Ivan Kokshaysky <ink(a)jurassic.park.msu.ru> To: Matt Turner <mattst88(a)gmail.com> To: Vineet Gupta <vgupta(a)kernel.org> To: Russell King <linux(a)armlinux.org.uk> To: Guo Ren <guoren(a)kernel.org> To: Huacai Chen <chenhuacai(a)kernel.org> To: WANG Xuerui <kernel(a)xen0n.name> To: Thomas Bogendoerfer <tsbogend(a)alpha.franken.de> To: James E.J. Bottomley <James.Bottomley(a)HansenPartnership.com> To: Helge Deller <deller(a)gmx.de> To: Michael Ellerman <mpe(a)ellerman.id.au> To: Nicholas Piggin <npiggin(a)gmail.com> To: Christophe Leroy <christophe.leroy(a)csgroup.eu> To: Naveen N Rao <naveen(a)kernel.org> To: Alexander Gordeev <agordeev(a)linux.ibm.com> To: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> To: Heiko Carstens <hca(a)linux.ibm.com> To: Vasily Gorbik <gor(a)linux.ibm.com> To: Christian Borntraeger <borntraeger(a)linux.ibm.com> To: Sven Schnelle <svens(a)linux.ibm.com> To: Yoshinori Sato <ysato(a)users.sourceforge.jp> To: Rich Felker <dalias(a)libc.org> To: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> To: David S. Miller <davem(a)davemloft.net> To: Andreas Larsson <andreas(a)gaisler.com> To: Thomas Gleixner <tglx(a)linutronix.de> To: Ingo Molnar <mingo(a)redhat.com> To: Borislav Petkov <bp(a)alien8.de> To: Dave Hansen <dave.hansen(a)linux.intel.com> To: x86(a)kernel.org To: H. Peter Anvin <hpa(a)zytor.com> To: Andy Lutomirski <luto(a)kernel.org> To: Peter Zijlstra <peterz(a)infradead.org> To: Muchun Song <muchun.song(a)linux.dev> To: Andrew Morton <akpm(a)linux-foundation.org> To: Liam R. Howlett <Liam.Howlett(a)oracle.com> To: Vlastimil Babka <vbabka(a)suse.cz> To: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> To: Shuah Khan <shuah(a)kernel.org> To: Christoph Hellwig <hch(a)infradead.org> To: Michal Hocko <mhocko(a)suse.com> To: "Kirill A. Shutemov" <kirill(a)shutemov.name> To: Chris Torek <chris.torek(a)gmail.com> Cc: linux-arch(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-alpha(a)vger.kernel.org Cc: linux-snps-arc(a)lists.infradead.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-csky(a)vger.kernel.org Cc: loongarch(a)lists.linux.dev Cc: linux-mips(a)vger.kernel.org Cc: linux-parisc(a)vger.kernel.org Cc: linuxppc-dev(a)lists.ozlabs.org Cc: linux-s390(a)vger.kernel.org Cc: linux-sh(a)vger.kernel.org Cc: sparclinux(a)vger.kernel.org Cc: linux-mm(a)kvack.org Cc: linux-kselftest(a)vger.kernel.org Cc: linux-abi-devel(a)lists.sourceforge.net Signed-off-by: Charlie Jenkins <charlie(a)rivosinc.com> Changes in v2: - Added much greater detail to cover letter - Removed all code that touched architecture specific code and was able to factor this out into all generic functions, except for flags that needed to be added to vm_unmapped_area_info - Made this an RFC since I have only tested it on riscv and x86 - Link to v1: https://lore.kernel.org/r/20240827-patches-below_hint_mmap-v1-0-46ff2eb9022… Changes in v3: - Use a personality flag instead of an mmap flag - Link to v2: https://lore.kernel.org/r/20240829-patches-below_hint_mmap-v2-0-638a28d9eae… --- Charlie Jenkins (2): mm: Add personality flag to limit address to 47 bits selftests/mm: Create ADDR_LIMIT_47BIT test include/uapi/linux/personality.h | 1 + mm/mmap.c | 3 ++ tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/map_47bit_personality.c | 34 ++++++++++++++++++++++ 5 files changed, 40 insertions(+) --- base-commit: 5be63fc19fcaa4c236b307420483578a56986a37 change-id: 20240827-patches-below_hint_mmap-b13d79ae1c55 -- - Charlie

6 months, 2 weeks

12
39
0 0

[PATCH v3 1/2] exec: fix up /proc/pid/comm in the execveat(AT_EMPTY_PATH) case

by Tycho Andersen

From: Tycho Andersen <tandersen(a)netflix.com> Zbigniew mentioned at Linux Plumber's that systemd is interested in switching to execveat() for service execution, but can't, because the contents of /proc/pid/comm are the file descriptor which was used, instead of the path to the binary. This makes the output of tools like top and ps useless, especially in a world where most fds are opened CLOEXEC so the number is truly meaningless. Change exec path to fix up /proc/pid/comm in the case where we have allocated one of these synthetic paths in bprm_init(). This way the actual exec machinery is unchanged, but cosmetically the comm looks reasonable to admins investigating things. Signed-off-by: Tycho Andersen <tandersen(a)netflix.com> Suggested-by: Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> CC: Aleksa Sarai <cyphar(a)cyphar.com> Link: https://github.com/uapi-group/kernel-features#set-comm-field-before-exec --- v2: * drop the flag, everyone :) * change the rendered value to f_path.dentry->d_name.name instead of argv[0], Eric v3: * fix up subject line, Eric --- fs/exec.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index dad402d55681..9520359a8dcc 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1416,7 +1416,18 @@ int begin_new_exec(struct linux_binprm * bprm) set_dumpable(current->mm, SUID_DUMP_USER); perf_event_exec(); - __set_task_comm(me, kbasename(bprm->filename), true); + + /* + * If fdpath was set, execveat() made up a path that will + * probably not be useful to admins running ps or similar. + * Let's fix it up to be something reasonable. + */ + if (bprm->fdpath) { + BUILD_BUG_ON(TASK_COMM_LEN > DNAME_INLINE_LEN); + __set_task_comm(me, bprm->file->f_path.dentry->d_name.name, true); + } else { + __set_task_comm(me, kbasename(bprm->filename), true); + } /* An exec changes our domain. We are no longer part of the thread group */ base-commit: baeb9a7d8b60b021d907127509c44507539c15e5 -- 2.34.1

6 months, 2 weeks

4
6
0 0

[PATCH RFC v4 0/9] 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. Introduce the code to compute hashes to the kernel in order to overcome thse challenges. An alternative solution is to extend the eBPF steering program so that it will be able to report to the userspace, but it is based on context rewrites, which is in feature freeze. We can adopt kfuncs, but they will not be UAPIs. We opt to ioctl to align with other relevant UAPIs (KVM and vhost_net). The patches for QEMU to use this new feature was submitted as RFC and is available at: https://patchew.org/QEMU/20240915-hash-v3-0-79cb08d28647@daynix.com/ This work was presented at LPC 2024: https://lpc.events/event/18/contributions/1963/ V1 -> V2: Changed to introduce a new BPF program type. Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com> --- Changes in v4: - Moved tun_vnet_hash_ext to if_tun.h. - Renamed virtio_net_toeplitz() to virtio_net_toeplitz_calc(). - Replaced htons() with cpu_to_be16(). - Changed virtio_net_hash_rss() to return void. - Reordered variable declarations in virtio_net_hash_rss(). - Removed virtio_net_hdr_v1_hash_from_skb(). - Updated messages of "tap: Pad virtio header with zero" and "tun: Pad virtio header with zero". - Fixed vnet_hash allocation size. - Ensured to free vnet_hash when destructing tun_struct. - Link to v3: https://lore.kernel.org/r/20240915-rss-v3-0-c630015db082@daynix.com Changes in v3: - Reverted back to add ioctl. - Split patch "tun: Introduce virtio-net hashing feature" into "tun: Introduce virtio-net hash reporting feature" and "tun: Introduce virtio-net RSS". - Changed to reuse hash values computed for automq instead of performing RSS hashing when hash reporting is requested but RSS is not. - Extracted relevant data from struct tun_struct to keep it minimal. - Added kernel-doc. - Changed to allow calling TUNGETVNETHASHCAP before TUNSETIFF. - Initialized num_buffers with 1. - Added a test case for unclassified packets. - Fixed error handling in tests. - Changed tests to verify that the queue index will not overflow. - Rebased. - Link to v2: https://lore.kernel.org/r/20231015141644.260646-1-akihiko.odaki@daynix.com --- Akihiko Odaki (9): skbuff: Introduce SKB_EXT_TUN_VNET_HASH virtio_net: Add functions for hashing net: flow_dissector: Export flow_keys_dissector_symmetric tap: Pad virtio header with zero tun: Pad virtio header with zero tun: Introduce virtio-net hash reporting feature tun: Introduce virtio-net RSS selftest: tun: Add tests for virtio-net hashing vhost/net: Support VIRTIO_NET_F_HASH_REPORT Documentation/networking/tuntap.rst | 7 + drivers/net/Kconfig | 1 + drivers/net/tap.c | 2 +- drivers/net/tun.c | 255 ++++++++++++-- drivers/vhost/net.c | 16 +- include/linux/if_tun.h | 5 + include/linux/skbuff.h | 3 + include/linux/virtio_net.h | 174 +++++++++ include/net/flow_dissector.h | 1 + include/uapi/linux/if_tun.h | 71 ++++ net/core/flow_dissector.c | 3 +- net/core/skbuff.c | 4 + tools/testing/selftests/net/Makefile | 2 +- tools/testing/selftests/net/tun.c | 666 ++++++++++++++++++++++++++++++++++- 14 files changed, 1170 insertions(+), 40 deletions(-) --- base-commit: 752ebcbe87aceeb6334e846a466116197711a982 change-id: 20240403-rss-e737d89efa77 Best regards, -- Akihiko Odaki <akihiko.odaki(a)daynix.com>

6 months, 2 weeks

4
22
0 0

[PATCH bpf-next v3 0/2] Support eliding map lookup nullness

by Daniel Xu

This patch allows progs to elide a null check on statically known map lookup keys. In other words, if the verifier can statically prove that the lookup will be in-bounds, allow the prog to drop the null check. This is useful for two reasons: 1. Large numbers of nullness checks (especially when they cannot fail) unnecessarily pushes prog towards BPF_COMPLEXITY_LIMIT_JMP_SEQ. 2. It forms a tighter contract between programmer and verifier. For (1), bpftrace is starting to make heavier use of percpu scratch maps. As a result, for user scripts with large number of unrolled loops, we are starting to hit jump complexity verification errors. These percpu lookups cannot fail anyways, as we only use static key values. Eliding nullness probably results in less work for verifier as well. For (2), percpu scratch maps are often used as a larger stack, as the currrent stack is limited to 512 bytes. In these situations, it is desirable for the programmer to express: "this lookup should never fail, and if it does, it means I messed up the code". By omitting the null check, the programmer can "ask" the verifier to double check the logic. Changes in v3: * Check if stack is (erroneously) growing upwards * Mention in commit message why existing tests needed change Changes in v2: * Added a check for when R2 is not a ptr to stack * Added a check for when stack is uninitialized (no stack slot yet) * Updated existing tests to account for null elision * Added test case for when R2 can be both const and non-const Daniel Xu (2): bpf: verifier: Support eliding map lookup nullness bpf: selftests: verifier: Add nullness elision tests kernel/bpf/verifier.c | 67 ++++++- tools/testing/selftests/bpf/progs/iters.c | 14 +- .../selftests/bpf/progs/map_kptr_fail.c | 2 +- .../bpf/progs/verifier_array_access.c | 166 ++++++++++++++++++ .../selftests/bpf/progs/verifier_map_in_map.c | 2 +- .../testing/selftests/bpf/verifier/map_kptr.c | 2 +- 6 files changed, 242 insertions(+), 11 deletions(-) -- 2.46.0

6 months, 2 weeks

3
6
0 0

kselftest/fixes build: 6 builds: 2 failed, 4 passed, 1 warning (v6.12-rc1-7-g160c826b4dd0d)

by kernelci.org bot

kselftest/fixes build: 6 builds: 2 failed, 4 passed, 1 warning (v6.12-rc1-7-g160c826b4dd0d) Full Build Summary: https://kernelci.org/build/kselftest/branch/fixes/kernel/v6.12-rc1-7-g160c8… Tree: kselftest Branch: fixes Git Describe: v6.12-rc1-7-g160c826b4dd0d Git Commit: 160c826b4dd0d570f0f51cf002cb49bda807e9f5 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git Built: 4 unique architectures Build Failures Detected: arm64: defconfig+kselftest+arm64-chromebook: (clang-16) FAIL defconfig+kselftest+arm64-chromebook: (gcc-12) FAIL Warnings Detected: arm64: arm: i386: x86_64: x86_64_defconfig+kselftest (clang-16): 1 warning Warnings summary: 1 vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x23: relocation to !ENDBR: .text+0x14fd19 ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- defconfig+kselftest+arm64-chromebook (arm64, gcc-12) — FAIL, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- defconfig+kselftest+arm64-chromebook (arm64, clang-16) — FAIL, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- i386_defconfig+kselftest (i386, gcc-12) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- multi_v7_defconfig+kselftest (arm, gcc-12) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, clang-16) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x23: relocation to !ENDBR: .text+0x14fd19 -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, gcc-12) — PASS, 0 errors, 0 warnings, 0 section mismatches --- For more info write to <info(a)kernelci.org>

6 months, 2 weeks

1
0
0 0

[PATCH v3 0/2] Exposing nice CPU usage to userspace

by Joshua Hahn

From: Joshua Hahn <joshua.hahn6(a)gmail.com> v2 -> v3: Signed-off-by & renamed subject for clarity. v1 -> v2: Edited commit messages for clarity. Niced CPU usage is a metric reported in host-level /prot/stat, but is not reported in cgroup-level statistics in cpu.stat. However, when a host contains multiple tasks across different workloads, it becomes difficult to gauge how much of the task is being spent on niced processes based on /proc/stat alone, since host-level metrics do not provide this cgroup-level granularity. Exposing this metric will allow users to accurately probe the niced CPU metric for each workload, and make more informed decisions when directing higher priority tasks. Joshua Hahn (2): Tracking cgroup-level niced CPU time Selftests for niced CPU statistics include/linux/cgroup-defs.h | 1 + kernel/cgroup/rstat.c | 16 ++++- tools/testing/selftests/cgroup/test_cpu.c | 72 +++++++++++++++++++++++ 3 files changed, 86 insertions(+), 3 deletions(-) -- 2.43.5

6 months, 2 weeks

3
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror October 2024