- Linux-kselftest-mirror - lists.linaro.org

Testing Quality Call notes - 2024-06-27

by Laura Nao

Hello, KernelCI is hosting a bi-weekly call on Thursday to discuss improvements to existing upstream tests, the development of new tests to increase kernel testing coverage, and the enablement of these tests in KernelCI. In recent months, we at Collabora have focused on various kernel areas, assessing the tests already available upstream and contributing patches to make them easily runnable in CIs. Below is a list of the tests we've been working on and their latest status updates, as discussed in the last meeting held on 2024-06-27: *USB/PCI devices kselftest* - Upstream test to detect unprobed devices on discoverable buses: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… - Kernel patches to allow running the test on more platforms on KernelCI were merged: https://lore.kernel.org/all/20240613-kselftest-discoverable-probe-mt8195-kc… - Waiting for KernelCI PRs to be merged: https://github.com/kernelci/kernelci-core/pull/2577 and https://github.com/kernelci/kernelci-pipeline/pull/642 *Error log test* - Proposing new kselftest to report device log errors: https://lore.kernel.org/all/20240423-dev-err-log-selftest-v1-0-690c1741d68b… - Currently fixing test failures in KernelCI *Suspend/resume in cpufreq kselftest* - Enabling suspend/resume test within the cpufreq kselftest in KernelCI - Parameter support for running subtests in a kselftest was merged: https://github.com/Linaro/test-definitions/pull/511 - Added rtcwake support in the test to enable automated resume, currently testing/debugging solution *Boot time test* - Investigating possibility of adding new test upstream to measure the kernel boot time and detect regressions - Currently looking into boot tracing with ftrace events and kprobes (see: https://www.kernel.org/doc/html/latest/trace/boottime-trace.html) - Idea for potential kselftest: insert explicit tracepoints in strategic places, let the user configure which times to measure. The test could provide a bootconfig file and a fragment to enable the required configs. This could be an alternative to using external tools (e.g. grabserial w/ early serial port init). - Need a list of functions to track in order to measure key metrics (e.g. device tree overhead, probe overhead, module load overhead) - Identify key drivers that need to be loaded early, for potentially supporting a two-phase boot: (1) time-critical, and (2) rest of the system *Other interesting updates* - Flaky serial on sc7180 was recently fixed: https://github.com/kernelci/kernelci-project/issues/380 and https://lore.kernel.org/all/20240610222515.3023730-1-dianders@chromium.org/… *Strategy for test enablement in KernelCI* - Guidance on test quality: KernelCI should set the standard for test quality, providing guidance on which tests to enable from various projects (e.g., kselftest, LTP). By doing so, KernelCI can serve as a model for other CI systems. - Develop mechanisms to automatically detect which tests should run on a specific platform - Embed metadata in the test themselves to facilitate the test selection process - Leverage device tree info to determine the appropriate tests for each platform Please reply to this thread if you'd like to join the call or discuss any of the topics further. We look forward to collaborating with the community to improve upstream tests and expand coverage to more areas of interest within the kernel. Best regards, Laura Nao

1 year, 5 months

1
0
0 0

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

by Maciej Wieczor-Retman

Changes v2: - Removed patches 2 and 3 since now this part will be supported by the kernel. Sub-Numa Clustering (SNC) allows splitting CPU cores, caches and memory into multiple NUMA nodes. When enabled, NUMA-aware applications can achieve better performance on bigger server platforms. SNC support in the kernel is currently in review [1]. With SNC enabled and kernel support in place all the tests will function normally. There might be a problem when SNC is enabled but the system is still using an older kernel version without SNC support. Currently the only message displayed in that situation is a guess that SNC might be enabled and is causing issues. That message also is displayed whenever the test fails on an Intel platform. Add a mechanism to discover kernel support for SNC which will add more meaning and certainty to the error message. Series was tested on Ice Lake server platforms with SNC disabled, SNC-2 and SNC-4. The tests were also ran with and without kernel support for SNC. Series applies cleanly on kselftest/next. [1] https://lore.kernel.org/all/20240503203325.21512-1-tony.luck@intel.com/ Previous versions of this series: [v1] https://lore.kernel.org/all/cover.1709721159.git.maciej.wieczor-retman@inte… Maciej Wieczor-Retman (2): selftests/resctrl: Adjust effective L3 cache size with SNC enabled selftests/resctrl: Adjust SNC support messages tools/testing/selftests/resctrl/cat_test.c | 2 +- tools/testing/selftests/resctrl/cmt_test.c | 6 +- tools/testing/selftests/resctrl/mba_test.c | 2 + tools/testing/selftests/resctrl/mbm_test.c | 4 +- tools/testing/selftests/resctrl/resctrl.h | 8 +- tools/testing/selftests/resctrl/resctrlfs.c | 131 +++++++++++++++++++- 6 files changed, 144 insertions(+), 9 deletions(-) -- 2.45.0

1 year, 5 months

3
18
0 0

[PATCH v3 0/2] Allow userspace to change ID_AA64PFR1_EL1

by Shaoqin Huang

Allow userspace to change the guest-visible value of the register with some severe limitation: - No changes to features not virtualized by KVM (MPAM_frac, RAS_frac, SME, RNDP_trap). - No changes to features (CSV2_frac, NMI, MTE_frac, GCS, THE, MTEX, DF2, PFAR) which haven't been added into the ftr_id_aa64pfr1[]. Because the struct arm64_ftr_bits definition for each feature in the ftr_id_aa64pfr1[] is used by arm64_check_features. If they're not existing in the ftr_id_aa64pfr1[], the for loop won't check the if the new_val is safe for those features. For the question why can't those fields be hidden depending on the VM configuration? I don't find there is the related VM configuration, maybe we should add the new VM configuration? I'm not sure I'm right, so if there're any problems please help to point out and I will fix them. Also add the selftest for it. Changelog: ---------- v2 -> v3: * Give more description about why only part of the fields can be writable. * Updated the writable mask by referring the latest ARM spec. v1 -> v2: * Tackling the full register instead of single field. * Changing the patch title and commit message. RFCv1 -> v1: * Fix the compilation error. * Delete the machine specific information and make the description more generable. RFCv1: https://lore.kernel.org/all/20240612023553.127813-1-shahuang@redhat.com/ v1: https://lore.kernel.org/all/20240617075131.1006173-1-shahuang@redhat.com/ v2: https://lore.kernel.org/all/20240618063808.1040085-1-shahuang@redhat.com/ Shaoqin Huang (2): KVM: arm64: Allow userspace to change ID_AA64PFR1_EL1 KVM: selftests: aarch64: Add writable test for ID_AA64PFR1_EL1 arch/arm64/kvm/sys_regs.c | 4 +++- tools/testing/selftests/kvm/aarch64/set_id_regs.c | 8 ++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) -- 2.40.1

1 year, 5 months

1
1
0 0

selftests/ftrace kprobe_eventname test fails on s390x QEMU (KVM/Linux)

by Yunseong Kim

Hi all, In my s390x archtecture, kprobe_eventname selftest have always failed because of rcu_sched stalls. My environment is QEMU Ubuntu 24.04 KVM Machine Linux version 6.8.0-36-generic (buildd@bos01-s390x-012) (s390x-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #36 1 configured CPUs, Linux is running under KVM in 64-bit mode qemu-system-s390x -no-reboot -name auto-inst-test -nographic -m 4096 \ -drive file=disk-image.qcow2,format=qcow2,cache=none,if=virtio \ -netdev user,id=enc0,hostfwd=tcp::10000-:22 \ -device virtio-net-ccw,netdev=enc0 \ -qmp tcp:localhost:4444,server,nowait Currently, This failure can be always reproduced by this kselftests script: # tools/testing/selftests/ftrace/ftracetest tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc I've investigating cause of line, then I find this line. for i in `seq 0 255`; do echo p $FUNCTION_FORK+${i} >> kprobe_events || continue done cat kprobe_events >> $testlog echo 1 > events/kprobes/enable # <<< This line makes "rcu_sched detected stalls" log and stall the system. [ 7825.578940] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: After this line, the test doesn't go any further. This test was added in the patch below. ("selftests/ftrace: Add new test case which adds multiple consecutive probes in a function") Link: https://lore.kernel.org/linux-trace-kernel/20230428163842.95118-2-akanksha@… I've attached a link to a compressed version of vmcore, vmlinux and config files that I dumped from my environment. https://drive.google.com/file/d/1O2bCKrRbyJ-yP4zTz_sAd_qM80nHnCGr/view?usp=… I used QEMU QMP to dump the vmcore. $ telnet localhost 4444 {"execute": "qmp_capabilities"} {"execute":"dump-guest-memory","arguments": {"paging":false,"protocol":"file:/home/paran/vmcore1.img"}} rcu: INFO: rcu_sched detected stalls on CPUs/tasks:s: rcu: (detected by 0, t=6002 jiffies, g=24353, q=1 ncpus=1)1) rcu: All QSes seen, last rcu_sched kthread activity 6002 (4294978930-4294972928), jiffies_till_next_fqs=1, root ->qsmask 0x0x0 rcu: rcu_sched kthread starved for 6002 jiffies! g24353 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0=0 rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.r. rcu: RCU grace-period kthread stack dump:p: task:rcu_sched state:R running task stack:0 pid:16 tgid:16 ppid:2 flags:0x0000000000 Call Trace:e: __schedule+0x346/0x8b8 8 schedule+0x36/0x148 8 schedule_timeout+0x8e/0x148 8 rcu_gp_fqs_loop+0x444/0x548 8 rcu_gp_kthread+0x146/0x198 8 kthread+0x124/0x128 8 __ret_from_fork+0x40/0x58 8 ret_from_fork+0xa/0x30 0 rcu: Stack dump where RCU GP kthread last ran:n: CPU: 0 PID: 1077 Comm: ftracetest Not tainted 6.8.0-36-generic #36-Ubuntu Hardware name: QEMU 8561 QEMU (KVM/Linux) Krnl PSW : 0704f00180000000 0000000000121d32 kprobe_exceptions_notify (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/kprobes.c:519 (discriminator 1)) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3:3 Krnl GPRS: 0000000000000000 0000000000000000 0000000000008001 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000001956720 ffffffffffffffff 0000000000121c98 0000000001958d40 00000380000cfbd8 000003ff938dbc78 00000380000cfab8 0000000000121d1c 00000380000cf980 Krnl Code: 0000000000121d26: 9103b008 Code starting with the faulting instruction =========================================== 8(%r11),3 0000000000121d2a: a7840004 8,0000000000121d32 #0000000000121d2e: ad03f0a0 stosm 160(%r15),3 >0000000000121d32: b9140022 lgfr %r2,%r2 0000000000121d36: ebbff0a80004 %r11,%r15,168(%r15) 0000000000121d3c: a7190000 lghi %r1,0 0000000000121d40: a7390000 lghi %r3,0 0000000000121d44: a7490000 lghi %r4,0 Call Trace: kprobe_exceptions_notify (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/kprobes.c:519 (discriminator 1)) kprobe_exceptions_notify (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/kprobes.c:504 (discriminator 1)) notifier_call_chain (/build/linux-3nCxw2/linux-6.8.0/kernel/notifier.c:93) notify_die (/build/linux-3nCxw2/linux-6.8.0/kernel/notifier.c:597) do_per_trap (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/traps.c:75 (discriminator 1)) __do_pgm_check (/build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/irqflags.h:47 (discriminator 1) /build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/irqflags.h:52 (discriminator 1) /build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/traps.c:356 (discriminator 1)) pgm_check_handler (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/entry.S:383) kernel_clone (/build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/uaccess.h:119 (discriminator 1) /build/linux-3nCxw2/linux-6.8.0/kernel/fork.c:2927 (discriminator 1)) __do_sys_clone (/build/linux-3nCxw2/linux-6.8.0/kernel/fork.c:3055) __s390x_sys_clone (/build/linux-3nCxw2/linux-6.8.0/kernel/fork.c:3027) __do_syscall (/build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/ptrace.h:195 (discriminator 3) /build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/ptrace.h:200 (discriminator 3) /build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/syscall.c:145 (discriminator 3) /build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/syscall.c:168 (discriminator 3)) system_call (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/entry.S:309) Last Breaking-Event-Address: 0xfdf5045050 ?rcu: INFO: rcu_sched detected stalls on CPUs/tasks:s: @rcu: (detected by 0, t=24007 jiffies, g=24353, q=1 ncpus=1) rcu: All QSes seen, last rcu_sched kthread activity 24007 (4294996935-4294972928), jiffies_till_next_fqs=1, root ->qsmask 0x0x0 rcu: rcu_sched kthread starved for 24007 jiffies! g24353 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0=0 rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.r. rcu: RCU grace-period kthread stack dump:p: task:rcu_sched state:R running task stack:0 pid:16 tgid:16 ppid:2 flags:0x0000000000 Call Trace:e: __schedule+0x346/0x8b8 8 schedule+0x36/0x148 8 schedule_timeout+0x8e/0x148 8 rcu_gp_fqs_loop+0x444/0x548 8 rcu_gp_kthread+0x146/0x198 8 kthread+0x124/0x128 8 __ret_from_fork+0x40/0x58 8 ret_from_fork+0xa/0x30 0 rcu: Stack dump where RCU GP kthread last ran:n: CPU: 0 PID: 1077 Comm: ftracetest Not tainted 6.8.0-36-generic #36-Ubuntu Hardware name: QEMU 8561 QEMU (KVM/Linux) Krnl PSW : 0704d00180000000 0000000000ebe0b2 __do_pgm_check (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/traps.c:353) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3:3 Krnl GPRS: 0704c00180000000 0000000000000000 00000380000cfb97 0000000000000000 0000000000000000 0704c00180000000 0000000000000000 0000000000000000 0704c00180000000 00000000001a8388 0000000000000000 00000380000cfbd8 000003ff938dbc78 0000000000ed1c6c 0000000000ebe024 00000380000cfaf0 Krnl Code: 0000000000ebe0a4: a504bfff Code starting with the faulting instruction =========================================== nihh %r0,49151 0000000000ebe0a8: e300f0a80024 %r0,168(%r15) #0000000000ebe0ae: 8000f0a8 168(%r15) >0000000000ebe0b2: 5850b0a0 %r5,160(%r11) 0000000000ebe0b6: c05b0000007f nilf %r5,127 0000000000ebe0bc: a7840012 8,0000000000ebe0e0 0000000000ebe0c0: b91600e5 llgfr %r14,%r5 0000000000ebe0c4: c0400051121e larl %r4,00000000018e0500 Call Trace: __do_pgm_check (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/traps.c:353) __do_pgm_check (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/traps.c:318) pgm_check_handler (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/entry.S:383) kernel_clone (/build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/uaccess.h:119 (discriminator 1) /build/linux-3nCxw2/linux-6.8.0/kernel/fork.c:2927 (discriminator 1)) __do_sys_clone (/build/linux-3nCxw2/linux-6.8.0/kernel/fork.c:3055) __s390x_sys_clone (/build/linux-3nCxw2/linux-6.8.0/kernel/fork.c:3027) __do_syscall (/build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/ptrace.h:195 (discriminator 3) /build/linux-3nCxw2/linux-6.8.0/arch/s390/include/asm/ptrace.h:200 (discriminator 3) /build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/syscall.c:145 (discriminator 3) /build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/syscall.c:168 (discriminator 3)) system_call (/build/linux-3nCxw2/linux-6.8.0/arch/s390/kernel/entry.S:309) Last Breaking-Event-Address: 0x4404c0018000000000 It's not easy for me to resolve this issue. If advice or guidance can be provided on how to resolve this issue, I'll try sending a patch! Warm regards, Yunseong Kim

1 year, 5 months

4
4
0 0

[PATCH v2 0/5] Reorganize string-stream and assert tests

by Ivan Orlov

Currently, we can run string-stream and assertion tests only when they are built into the kernel (with config options = y), since some of the symbols (string-stream functions and functions from assert.c) are not exported into any of the namespaces, therefore they are not accessible for the modules. This patch series exports the required symbols into the KUnit namespace. Also, it makes the string-stream test a separate module and removes the log test stub from kunit-test since now we can access the string-stream symbols even if the test which uses it is built as a module. Additionally, this patch series merges the assertion test suite into the kunit-test, since assert.c (and all of the assertion formatting functions in it) is a part of the KUnit core. V1 -> V2: - Patch which exports the non-static assert.c functions is replaced with the patch which prepares assert_test.c to be merged into kunit-test.c - Also, David Gow <davidgow(a)google.com> suggested merging 4th and 5th patches together, but since now the 4th patch does more than it used to do, I send it separately Ivan Orlov (5): kunit: string-stream: export non-static functions kunit: kunit-test: Remove stub for log tests kunit: string-stream-test: Make it a separate module kunit: assert_test: Prepare to be merged into kunit-test.c kunit: Merge assertion test into kunit-test.c include/kunit/assert.h | 4 +- lib/kunit/Kconfig | 8 + lib/kunit/Makefile | 7 +- lib/kunit/assert.c | 19 +- lib/kunit/assert_test.c | 388 -------------------------------- lib/kunit/kunit-test.c | 397 +++++++++++++++++++++++++++++++-- lib/kunit/string-stream-test.c | 2 + lib/kunit/string-stream.c | 12 +- 8 files changed, 416 insertions(+), 421 deletions(-) delete mode 100644 lib/kunit/assert_test.c -- 2.34.1

1 year, 5 months

3
14
0 0

[PATCH net-next v14 00/13] Device Memory TCP

by Mina Almasry

v14: https://patchwork.kernel.org/project/netdevbpf/list/?series=865135&archive=… ==== No material changes in this version. Only rebase and re-verification on top of net-next. v13, I think, raced with commit ebad6d0334793 ("net/ipv4: Use nested-BH locking for ipv4_tcp_sk.") being merged to net-next that caused a patchwork failure to apply. This series should apply cleanly on commit c4532232fa2a4 ("selftests: net: remove unneeded IP_GRE config"). I did not wait the customary 24hr as Jakub said it's OK to repost as soon as I build test the rebased version: https://lore.kernel.org/netdev/20240625075926.146d769d@kernel.org/ v13: https://patchwork.kernel.org/project/netdevbpf/list/?series=861406&archive=… ==== Major changes: -------------- This iteration addresses Pavel's review comments, applies his reviewed-by's, and seeks to fix the patchwork build error (sorry!). As usual, the full devmem TCP changes including the full GVE driver implementation is here: https://github.com/mina/linux/commits/tcpdevmem-v13/ v12: https://patchwork.kernel.org/project/netdevbpf/list/?series=859747&state=* ==== Major changes: -------------- This iteration only addresses one minor comment from Pavel with regards to the trace printing of netmem, and the patchwork build error introduced in v11 because I missed doing an allmodconfig build, sorry. Other than that v11, AFAICT, received no feedback. There is one discussion about how the specifics of plugging io uring memory through the page pool, but not relevant to content in this particular patchset, AFAICT. As usual, the full devmem TCP changes including the full GVE driver implementation is here: https://github.com/mina/linux/commits/tcpdevmem-v12/ v11: https://patchwork.kernel.org/project/netdevbpf/list/?series=857457&state=* ==== Major Changes: -------------- v11 addresses feedback received in v10. The major change is the removal of the memory provider ops as requested by Christoph. We still accomplish the same thing, but utilizing direct function calls with if statements rather than generic ops. Additionally address sparse warnings, bugs and review comments from folks that reviewed. As usual, the full devmem TCP changes including the full GVE driver implementation is here: https://github.com/mina/linux/commits/tcpdevmem-v11/ Detailed changelog: ------------------- - Fixes in netdev_rx_queue_restart() from Pavel & David. - Remove commit e650e8c3a36f5 ("net: page_pool: create hooks for custom page providers") from the series to address Christoph's feedback and rebased other patches on the series on this change. - Fixed build errors with CONFIG_DMA_SHARED_BUFFER && !CONFIG_GENERIC_ALLOCATOR build. - Fixed sparse warnings pointed out by Paolo. - Drop unnecessary gro_pull_from_frag0 checks. - Added Bagas reviewed-by to docs. Cc: Bagas Sanjaya <bagasdotme(a)gmail.com> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Nikolay Aleksandrov <razor(a)blackwall.org> v10: https://patchwork.kernel.org/project/netdevbpf/list/?series=852422&state=* ==== Major Changes: -------------- v9 was sent right before the merge window closed (sorry!). v10 is almost a re-send of the series now that the merge window re-opened. Only rebased to latest net-next and addressed some minor iterative comments received on v9. As usual, the full devmem TCP changes including the full GVE driver implementation is here: https://github.com/mina/linux/commits/tcpdevmem-v10/ Detailed changelog: ------------------- - Fixed tokens leaking in DONTNEED setsockopt (Nikolay). - Moved net_iov_dma_addr() to devmem.c and made it a devmem specific helpers (David). - Rename hook alloc_pages to alloc_netmems as alloc_pages is now preprocessor macro defined and causes a build error. v9: === Major Changes: -------------- GVE queue API has been merged. Submitting this version as non-RFC after rebasing on top of the merged API, and dropped the out of tree queue API I was carrying on github. Addressed the little feedback v8 has received. Detailed changelog: ------------------ - Added new patch from David Wei to this series for netdev_rx_queue_restart() - Fixed sparse error. - Removed CONFIG_ checks in netmem_is_net_iov() - Flipped skb->readable to skb->unreadable - Minor fixes to selftests & docs. RFC v8: ======= Major Changes: -------------- - Fixed build error generated by patch-by-patch build. - Applied docs suggestions from Randy. RFC v7: ======= Major Changes: -------------- This revision largely rebases on top of net-next and addresses the feedback RFCv6 received from folks, namely Jakub, Yunsheng, Arnd, David, & Pavel. The series remains in RFC because the queue-API ndos defined in this series are not yet implemented. I have a GVE implementation I carry out of tree for my testing. A upstreamable GVE implementation is in the works. Aside from that, in my estimation all the patches are ready for review/merge. Please do take a look. As usual the full devmem TCP changes including the full GVE driver implementation is here: https://github.com/mina/linux/commits/tcpdevmem-v7/ Detailed changelog: - Use admin-perm in netlink API. - Addressed feedback from Jakub with regards to netlink API implementation. - Renamed devmem.c functions to something more appropriate for that file. - Improve the performance seen through the page_pool benchmark. - Fix the value definition of all the SO_DEVMEM_* uapi. - Various fixes to documentation. Perf - page-pool benchmark: --------------------------- Improved performance of bench_page_pool_simple.ko tests compared to v6: https://pastebin.com/raw/v5dYRg8L net-next base: 8 cycle fast path. RFC v6: 10 cycle fast path. RFC v7: 9 cycle fast path. RFC v7 with CONFIG_DMA_SHARED_BUFFER disabled: 8 cycle fast path, same as baseline. Perf - Devmem TCP benchmark: --------------------- Perf is about the same regardless of the changes in v7, namely the removal of the static_branch_unlikely to improve the page_pool benchmark performance: 189/200gbps bi-directional throughput with RX devmem TCP and regular TCP TX i.e. ~95% line rate. RFC v6: ======= Major Changes: -------------- This revision largely rebases on top of net-next and addresses the little feedback RFCv5 received. The series remains in RFC because the queue-API ndos defined in this series are not yet implemented. I have a GVE implementation I carry out of tree for my testing. A upstreamable GVE implementation is in the works. Aside from that, in my estimation all the patches are ready for review/merge. Please do take a look. As usual the full devmem TCP changes including the full GVE driver implementation is here: https://github.com/mina/linux/commits/tcpdevmem-v6/ This version also comes with some performance data recorded in the cover letter (see below changelog). Detailed changelog: - Rebased on top of the merged netmem_ref changes. - Converted skb->dmabuf to skb->readable (Pavel). Pavel's original suggestion was to remove the skb->dmabuf flag entirely, but when I looked into it closely, I found the issue that if we remove the flag we have to dereference the shinfo(skb) pointer to obtain the first frag to tell whether an skb is readable or not. This can cause a performance regression if it dirties the cache line when the shinfo(skb) was not really needed. Instead, I converted the skb->dmabuf flag into a generic skb->readable flag which can be re-used by io_uring 0-copy RX. - Squashed a few locking optimizations from Eric Dumazet in the RX path and the DEVMEM_DONTNEED setsockopt. - Expanded the tests a bit. Added validation for invalid scenarios and added some more coverage. Perf - page-pool benchmark: --------------------------- bench_page_pool_simple.ko tests with and without these changes: https://pastebin.com/raw/ncHDwAbn AFAIK the number that really matters in the perf tests is the 'tasklet_page_pool01_fast_path Per elem'. This one measures at about 8 cycles without the changes but there is some 1 cycle noise in some results. With the patches this regresses to 9 cycles with the changes but there is 1 cycle noise occasionally running this test repeatedly. Lastly I tried disable the static_branch_unlikely() in netmem_is_net_iov() check. To my surprise disabling the static_branch_unlikely() check reduces the fast path back to 8 cycles, but the 1 cycle noise remains. Perf - Devmem TCP benchmark: --------------------- 189/200gbps bi-directional throughput with RX devmem TCP and regular TCP TX i.e. ~95% line rate. Major changes in RFC v5: ======================== 1. Rebased on top of 'Abstract page from net stack' series and used the new netmem type to refer to LSB set pointers instead of re-using struct page. 2. Downgraded this series back to RFC and called it RFC v5. This is because this series is now dependent on 'Abstract page from net stack'[1] and the queue API. Both are removed from the series to reduce the patch # and those bits are fairly independent or pre-requisite work. 3. Reworked the page_pool devmem support to use netmem and for some more unified handling. 4. Reworked the reference counting of net_iov (renamed from page_pool_iov) to use pp_ref_count for refcounting. The full changes including the dependent series and GVE page pool support is here: https://github.com/mina/linux/commits/tcpdevmem-rfcv5/ [1] https://patchwork.kernel.org/project/netdevbpf/list/?series=810774 Major changes in v1: ==================== 1. Implemented MVP queue API ndos to remove the userspace-visible driver reset. 2. Fixed issues in the napi_pp_put_page() devmem frag unref path. 3. Removed RFC tag. Many smaller addressed comments across all the patches (patches have individual change log). Full tree including the rest of the GVE driver changes: https://github.com/mina/linux/commits/tcpdevmem-v1 Changes in RFC v3: ================== 1. Pulled in the memory-provider dependency from Jakub's RFC[1] to make the series reviewable and mergeable. 2. Implemented multi-rx-queue binding which was a todo in v2. 3. Fix to cmsg handling. The sticking point in RFC v2[2] was the device reset required to refill the device rx-queues after the dmabuf bind/unbind. The solution suggested as I understand is a subset of the per-queue management ops Jakub suggested or similar: https://lore.kernel.org/netdev/20230815171638.4c057dcd@kernel.org/ This is not addressed in this revision, because: 1. This point was discussed at netconf & netdev and there is openness to using the current approach of requiring a device reset. 2. Implementing individual queue resetting seems to be difficult for my test bed with GVE. My prototype to test this ran into issues with the rx-queues not coming back up properly if reset individually. At the moment I'm unsure if it's a mistake in the POC or a genuine issue in the virtualization stack behind GVE, which currently doesn't test individual rx-queue restart. 3. Our usecases are not bothered by requiring a device reset to refill the buffer queues, and we'd like to support NICs that run into this limitation with resetting individual queues. My thought is that drivers that have trouble with per-queue configs can use the support in this series, while drivers that support new netdev ops to reset individual queues can automatically reset the queue as part of the dma-buf bind/unbind. The same approach with device resets is presented again for consideration with other sticking points addressed. This proposal includes the rx devmem path only proposed for merge. For a snapshot of my entire tree which includes the GVE POC page pool support & device memory support: https://github.com/torvalds/linux/compare/master...mina:linux:tcpdevmem-v3 [1] https://lore.kernel.org/netdev/f8270765-a27b-6ccf-33ea-cda097168d79@redhat.… [2] https://lore.kernel.org/netdev/CAHS8izOVJGJH5WF68OsRWFKJid1_huzzUK+hpKbLcL4… Changes in RFC v2: ================== The sticking point in RFC v1[1] was the dma-buf pages approach we used to deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept that attempts to resolve this by implementing scatterlist support in the networking stack, such that we can import the dma-buf scatterlist directly. This is the approach proposed at a high level here[2]. Detailed changes: 1. Replaced dma-buf pages approach with importing scatterlist into the page pool. 2. Replace the dma-buf pages centric API with a netlink API. 3. Removed the TX path implementation - there is no issue with implementing the TX path with scatterlist approach, but leaving out the TX path makes it easier to review. 4. Functionality is tested with this proposal, but I have not conducted perf testing yet. I'm not sure there are regressions, but I removed perf claims from the cover letter until they can be re-confirmed. 5. Added Signed-off-by: contributors to the implementation. 6. Fixed some bugs with the RX path since RFC v1. Any feedback welcome, but specifically the biggest pending questions needing feedback IMO are: 1. Feedback on the scatterlist-based approach in general. 2. Netlink API (Patch 1 & 2). 3. Approach to handle all the drivers that expect to receive pages from the page pool (Patch 6). [1] https://lore.kernel.org/netdev/dfe4bae7-13a0-3c5d-d671-f61b375cb0b4@gmail.c… [2] https://lore.kernel.org/netdev/CAHS8izPm6XRS54LdCDZVd0C75tA1zHSu6jLVO8nzTLX… ================== * TL;DR: Device memory TCP (devmem TCP) is a proposal for transferring data to and/or from device memory efficiently, without bouncing the data to a host memory buffer. * Problem: A large amount of data transfers have device memory as the source and/or destination. Accelerators drastically increased the volume of such transfers. Some examples include: - ML accelerators transferring large amounts of training data from storage into GPU/TPU memory. In some cases ML training setup time can be as long as 50% of TPU compute time, improving data transfer throughput & efficiency can help improving GPU/TPU utilization. - Distributed training, where ML accelerators, such as GPUs on different hosts, exchange data among them. - Distributed raw block storage applications transfer large amounts of data with remote SSDs, much of this data does not require host processing. Today, the majority of the Device-to-Device data transfers the network are implemented as the following low level operations: Device-to-Host copy, Host-to-Host network transfer, and Host-to-Device copy. The implementation is suboptimal, especially for bulk data transfers, and can put significant strains on system resources, such as host memory bandwidth, PCIe bandwidth, etc. One important reason behind the current state is the kernel’s lack of semantics to express device to network transfers. * Proposal: In this patch series we attempt to optimize this use case by implementing socket APIs that enable the user to: 1. send device memory across the network directly, and 2. receive incoming network packets directly into device memory. Packet _payloads_ go directly from the NIC to device memory for receive and from device memory to NIC for transmit. Packet _headers_ go to/from host memory and are processed by the TCP/IP stack normally. The NIC _must_ support header split to achieve this. Advantages: - Alleviate host memory bandwidth pressure, compared to existing network-transfer + device-copy semantics. - Alleviate PCIe BW pressure, by limiting data transfer to the lowest level of the PCIe tree, compared to traditional path which sends data through the root complex. * Patch overview: ** Part 1: netlink API Gives user ability to bind dma-buf to an RX queue. ** Part 2: scatterlist support Currently the standard for device memory sharing is DMABUF, which doesn't generate struct pages. On the other hand, networking stack (skbs, drivers, and page pool) operate on pages. We have 2 options: 1. Generate struct pages for dmabuf device memory, or, 2. Modify the networking stack to process scatterlist. Approach #1 was attempted in RFC v1. RFC v2 implements approach #2. ** part 3: page pool support We piggy back on page pool memory providers proposal: https://github.com/kuba-moo/linux/tree/pp-providers It allows the page pool to define a memory provider that provides the page allocation and freeing. It helps abstract most of the device memory TCP changes from the driver. ** part 4: support for unreadable skb frags Page pool iovs are not accessible by the host; we implement changes throughput the networking stack to correctly handle skbs with unreadable frags. ** Part 5: recvmsg() APIs We define user APIs for the user to send and receive device memory. Not included with this series is the GVE devmem TCP support, just to simplify the review. Code available here if desired: https://github.com/mina/linux/tree/tcpdevmem This series is built on top of net-next with Jakub's pp-providers changes cherry-picked. * NIC dependencies: 1. (strict) Devmem TCP require the NIC to support header split, i.e. the capability to split incoming packets into a header + payload and to put each into a separate buffer. Devmem TCP works by using device memory for the packet payload, and host memory for the packet headers. 2. (optional) Devmem TCP works better with flow steering support & RSS support, i.e. the NIC's ability to steer flows into certain rx queues. This allows the sysadmin to enable devmem TCP on a subset of the rx queues, and steer devmem TCP traffic onto these queues and non devmem TCP elsewhere. The NIC I have access to with these properties is the GVE with DQO support running in Google Cloud, but any NIC that supports these features would suffice. I may be able to help reviewers bring up devmem TCP on their NICs. * Testing: The series includes a udmabuf kselftest that show a simple use case of devmem TCP and validates the entire data path end to end without a dependency on a specific dmabuf provider. ** Test Setup Kernel: net-next with this series and memory provider API cherry-picked locally. Hardware: Google Cloud A3 VMs. NIC: GVE with header split & RSS & flow steering support. Cc: Pavel Begunkov <asml.silence(a)gmail.com> Cc: David Wei <dw(a)davidwei.uk> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Yunsheng Lin <linyunsheng(a)huawei.com> Cc: Shailend Chand <shailend(a)google.com> Cc: Harshitha Ramamurthy <hramamurthy(a)google.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Jeroen de Borst <jeroendb(a)google.com> Cc: Praveen Kaligineedi <pkaligineedi(a)google.com> Mina Almasry (13): netdev: add netdev_rx_queue_restart() net: netdev netlink api to bind dma-buf to a net device netdev: support binding dma-buf to netdevice netdev: netdevice devmem allocator page_pool: convert to use netmem page_pool: devmem support memory-provider: dmabuf devmem memory provider net: support non paged skb frags net: add support for skbs with unreadable frags tcp: RX path for devmem TCP net: add SO_DEVMEM_DONTNEED setsockopt to release RX frags net: add devmem TCP documentation selftests: add ncdevmem, netcat for devmem TCP Documentation/netlink/specs/netdev.yaml | 57 +++ Documentation/networking/devmem.rst | 258 +++++++++++ Documentation/networking/index.rst | 1 + arch/alpha/include/uapi/asm/socket.h | 6 + arch/mips/include/uapi/asm/socket.h | 6 + arch/parisc/include/uapi/asm/socket.h | 6 + arch/sparc/include/uapi/asm/socket.h | 6 + include/linux/skbuff.h | 61 ++- include/linux/skbuff_ref.h | 11 +- include/linux/socket.h | 1 + include/net/devmem.h | 124 ++++++ include/net/mp_dmabuf_devmem.h | 44 ++ include/net/netdev_rx_queue.h | 5 + include/net/netmem.h | 208 ++++++++- include/net/page_pool/helpers.h | 124 ++++-- include/net/page_pool/types.h | 22 +- include/net/sock.h | 2 + include/net/tcp.h | 5 +- include/trace/events/page_pool.h | 30 +- include/uapi/asm-generic/socket.h | 6 + include/uapi/linux/netdev.h | 19 + include/uapi/linux/uio.h | 17 + net/bpf/test_run.c | 5 +- net/core/Makefile | 3 +- net/core/datagram.c | 6 + net/core/dev.c | 6 +- net/core/devmem.c | 376 ++++++++++++++++ net/core/gro.c | 3 +- net/core/netdev-genl-gen.c | 23 + net/core/netdev-genl-gen.h | 6 + net/core/netdev-genl.c | 103 +++++ net/core/netdev_rx_queue.c | 74 ++++ net/core/page_pool.c | 362 +++++++++------- net/core/skbuff.c | 83 +++- net/core/sock.c | 61 +++ net/ipv4/esp4.c | 3 +- net/ipv4/tcp.c | 261 +++++++++++- net/ipv4/tcp_input.c | 13 +- net/ipv4/tcp_ipv4.c | 16 + net/ipv4/tcp_minisocks.c | 2 + net/ipv4/tcp_output.c | 5 +- net/ipv6/esp6.c | 3 +- net/packet/af_packet.c | 4 +- tools/include/uapi/linux/netdev.h | 19 + tools/testing/selftests/net/.gitignore | 1 + tools/testing/selftests/net/Makefile | 5 + tools/testing/selftests/net/ncdevmem.c | 542 ++++++++++++++++++++++++ 47 files changed, 2753 insertions(+), 251 deletions(-) create mode 100644 Documentation/networking/devmem.rst create mode 100644 include/net/devmem.h create mode 100644 include/net/mp_dmabuf_devmem.h create mode 100644 net/core/devmem.c create mode 100644 net/core/netdev_rx_queue.c create mode 100644 tools/testing/selftests/net/ncdevmem.c -- 2.45.2.741.gdbec12cfda-goog

1 year, 5 months

4
21
0 0

[PATCH v3 0/2] usercopy: Convert test_user_copy to KUnit test

by Kees Cook

Hi, This builds on the proposal[1] from Mark and lets me convert the existing usercopy selftest to KUnit. Besides adding this basic test to the KUnit collection, it also opens the door for execve testing (which depends on having a functional current->mm), and should provide the basic infrastructure for adding Mark's much more complete usercopy tests. v3: - use MEMEQ KUnit helper (David) - exclude pathological address confusion test for systems with separate address spaces, noticed by David - add KUnit-conditional exports for alloc_mm() and arch_pick_mmap_layout() noticed by 0day v2: https://lore.kernel.org/lkml/20240610213055.it.075-kees@kernel.org/ v1: https://lore.kernel.org/lkml/20240519190422.work.715-kees@kernel.org/ -Kees [1] https://lore.kernel.org/lkml/20230321122514.1743889-2-mark.rutland@arm.com/ Kees Cook (2): kunit: test: Add vm_mmap() allocation resource manager usercopy: Convert test_user_copy to KUnit test MAINTAINERS | 1 + include/kunit/test.h | 17 ++ kernel/fork.c | 3 + lib/Kconfig.debug | 21 +- lib/Makefile | 2 +- lib/kunit/Makefile | 1 + lib/kunit/user_alloc.c | 113 +++++++++ lib/{test_user_copy.c => usercopy_kunit.c} | 282 ++++++++++----------- mm/util.c | 3 + 9 files changed, 288 insertions(+), 155 deletions(-) create mode 100644 lib/kunit/user_alloc.c rename lib/{test_user_copy.c => usercopy_kunit.c} (46%) -- 2.34.1

1 year, 5 months

5
11
0 0

[PATCH v7 00/16] Add support for a few Zc* extensions, Zcmop and Zimop

by Clément Léger

Add support for (yet again) more RVA23U64 missing extensions. Add support for Zimop, Zcmop, Zca, Zcf, Zcd and Zcb extensions ISA string parsing, hwprobe and kvm support. Zce, Zcmt and Zcmp extensions have been left out since they target microcontrollers/embedded CPUs and are not needed by RVA23U64. Since Zc* extensions states that C implies Zca, Zcf (if F and RV32), Zcd (if D), this series modifies the way ISA string is parsed and now does it in two phases. First one parses the string and the second one validates it for the final ISA description. Link: https://lore.kernel.org/linux-riscv/20240404103254.1752834-1-cleger@rivosin… [1] Link: https://lore.kernel.org/all/20240409143839.558784-1-cleger@rivosinc.com/ [2] --- v7: - Rebased on riscv/for-next to fix conflicts v6: - Rebased on riscv/for-next - Remove ternary operator to use 'if()' instead in extension checks - v5: https://lore.kernel.org/all/20240517145302.971019-1-cleger@rivosinc.com/ v5: - Merged in Zimop to avoid any uneeded series dependencies - Rework dependency resolution loop to loop on source isa first rather than on all extension. - Disabled extensions in source isa once set in resolved isa - Rename riscv_resolve_isa() parameters - v4: https://lore.kernel.org/all/20240429150553.625165-1-cleger@rivosinc.com/ v4: - Modify validate() callbacks to return 0, -EPROBEDEFER or another error. - v3: https://lore.kernel.org/all/20240423124326.2532796-1-cleger@rivosinc.com/ v3: - Fix typo "exists" -> "exist" - Remove C implies Zca, Zcd, Zcf, dt-bindings rules - Rework ISA string resolver to handle dependencies - v2: https://lore.kernel.org/all/20240418124300.1387978-1-cleger@rivosinc.com/ v2: - Add Zc* dependencies validation in dt-bindings - v1: https://lore.kernel.org/lkml/20240410091106.749233-1-cleger@rivosinc.com/ Clément Léger (16): dt-bindings: riscv: add Zimop ISA extension description riscv: add ISA extension parsing for Zimop riscv: hwprobe: export Zimop ISA extension RISC-V: KVM: Allow Zimop extension for Guest/VM KVM: riscv: selftests: Add Zimop extension to get-reg-list test dt-bindings: riscv: add Zca, Zcf, Zcd and Zcb ISA extension description riscv: add ISA extensions validation callback riscv: add ISA parsing for Zca, Zcf, Zcd and Zcb riscv: hwprobe: export Zca, Zcf, Zcd and Zcb ISA extensions RISC-V: KVM: Allow Zca, Zcf, Zcd and Zcb extensions for Guest/VM KVM: riscv: selftests: Add some Zc* extensions to get-reg-list test dt-bindings: riscv: add Zcmop ISA extension description riscv: add ISA extension parsing for Zcmop riscv: hwprobe: export Zcmop ISA extension RISC-V: KVM: Allow Zcmop extension for Guest/VM KVM: riscv: selftests: Add Zcmop extension to get-reg-list test Documentation/arch/riscv/hwprobe.rst | 28 ++ .../devicetree/bindings/riscv/extensions.yaml | 95 ++++++ arch/riscv/include/asm/cpufeature.h | 1 + arch/riscv/include/asm/hwcap.h | 6 + arch/riscv/include/uapi/asm/hwprobe.h | 6 + arch/riscv/include/uapi/asm/kvm.h | 6 + arch/riscv/kernel/cpufeature.c | 277 ++++++++++++------ arch/riscv/kernel/sys_hwprobe.c | 6 + arch/riscv/kvm/vcpu_onereg.c | 12 + .../selftests/kvm/riscv/get-reg-list.c | 24 ++ 10 files changed, 375 insertions(+), 86 deletions(-) -- 2.45.2

1 year, 5 months

5
22
0 0

[PATCH v2] selftests/capabilities: Fix possible file leak in copy_fromat_to

by Ma Ke

The open() function returns -1 on error. openat() and open() initialize 'from' and 'to', and only 'from' validated with 'if' statement. If the initialization of variable 'to' fails, we should better check the value of 'to' and close 'from' to avoid possible file leak. Improve the checking of 'from' additionally. Fixes: 32ae976ed3b5 ("selftests/capabilities: Add tests for capability evolution") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch according to suggestions; - found by customized static analysis tool. --- tools/testing/selftests/capabilities/test_execve.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/capabilities/test_execve.c b/tools/testing/selftests/capabilities/test_execve.c index 47bad7ddc5bc..6406ab6aa1f5 100644 --- a/tools/testing/selftests/capabilities/test_execve.c +++ b/tools/testing/selftests/capabilities/test_execve.c @@ -145,10 +145,14 @@ static void chdir_to_tmpfs(void) static void copy_fromat_to(int fromfd, const char *fromname, const char *toname) { int from = openat(fromfd, fromname, O_RDONLY); - if (from == -1) + if (from < 0) ksft_exit_fail_msg("open copy source - %s\n", strerror(errno)); int to = open(toname, O_CREAT | O_WRONLY | O_EXCL, 0700); + if (to < 0) { + close(from); + ksft_exit_fail_msg("open copy destination - %s\n", strerror(errno)); + } while (true) { char buf[4096]; -- 2.25.1

1 year, 5 months

3
2
0 0

[PATCH] selftests/hid: ensure CKI can compile our new tests on old kernels

by Benjamin Tissoires

In the same way than commit ae7487d112cf ("selftests/hid: ensure we can compile the tests on kernels pre-6.3") we should expose struct hid_bpf_ops when it's not available in vmlinux.h. So unexpose an eventual struct hid_bpf_ops, include vmlinux.h, and re-export struct hid_bpf_ops. Fixes: d7696738d66b ("selftests/hid: convert the hid_bpf selftests with struct_ops") Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/r/202406270328.bscLN1IF-lkp@intel.com/ Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> --- Same situation than in an early report when HID-BPF was initially included: the automatically generated vmlinux.h doesn't contain all of the required structs and the compilation of the bpf program fails. --- tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h index c72e44321764..5a911f0e8625 100644 --- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h +++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h @@ -7,6 +7,7 @@ /* "undefine" structs and enums in vmlinux.h, because we "override" them below */ #define hid_bpf_ctx hid_bpf_ctx___not_used +#define hid_bpf_ops hid_bpf_ops___not_used #define hid_report_type hid_report_type___not_used #define hid_class_request hid_class_request___not_used #define hid_bpf_attach_flags hid_bpf_attach_flags___not_used @@ -24,6 +25,7 @@ #include "vmlinux.h" #undef hid_bpf_ctx +#undef hid_bpf_ops #undef hid_report_type #undef hid_class_request #undef hid_bpf_attach_flags @@ -68,6 +70,20 @@ enum hid_class_request { HID_REQ_SET_PROTOCOL = 0x0B, }; +struct hid_bpf_ops { + int hid_id; + u32 flags; + struct list_head list; + int (*hid_device_event)(struct hid_bpf_ctx *ctx, enum hid_report_type report_type, + __u64 source); + int (*hid_rdesc_fixup)(struct hid_bpf_ctx *ctx); + int (*hid_hw_request)(struct hid_bpf_ctx *ctx, unsigned char reportnum, + enum hid_report_type rtype, enum hid_class_request reqtype, + __u64 source); + int (*hid_hw_output_report)(struct hid_bpf_ctx *ctx, __u64 source); + struct hid_device *hdev; +}; + #ifndef BPF_F_BEFORE #define BPF_F_BEFORE (1U << 3) #endif --- base-commit: d3e15189bfd4d0a9d3a7ad8bd0e6ebb1c0419f93 change-id: 20240627-fix-cki-f372855cbf6f Best regards, -- Benjamin Tissoires <bentiss(a)kernel.org>

1 year, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror