On Thu, 5 Mar 2026 at 02:31, Samuel Wu <[email protected]> wrote: > > On Wed, Feb 25, 2026 at 1:08 PM Samuel Wu <[email protected]> wrote: > > > > This patch series introduces BPF iterators for wakeup_source, enabling > > BPF programs to efficiently traverse a device's wakeup sources. > > > > Currently, inspecting wakeup sources typically involves reading interfaces > > like /sys/class/wakeup/* or debugfs. The repeated syscalls to query the > > sysfs nodes is inefficient, as there can be hundreds of wakeup_sources, and > > each wakeup source have multiple stats, with one sysfs node per stat. > > debugfs is unstable and insecure. > > > > The iterators utilize pre-existing wakeup_sources_walk_* functions to > > traverse over the SRCU that backs the list of wakeup_sources. > > > > Changes in v5: > > - Add CORE definitions for *__local variables to fix s390 build per bpf-ci > > - v4 link: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v4: > > - Proper init of variables in ws_iter_check_sleep_times() test per bpf-ci > > - Remove PM patch since it's already part of rebase > > - v3 link: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v3: > > - Update wakeup_sources_walk_start() to handle an empty list per bpf-ci > > - Simplify read of a struct's field in BPF program selftest per Andrii > > - Drop open coded iterators for wakeup_sources > > - Fix condition from !get_ws_iter_stream to get_ws_iter_stream in selftest > > - Read event_count instead of wakeup_count in selftest > > - v2 link: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v2: > > - Guard BPF Makefile with CONFIG_PM_SLEEP to fix build errors > > - Update copyright from 2025 to 2026 > > - v1 link: > > https://lore.kernel.org/all/[email protected]/ > > > > > > Samuel Wu (2): > > bpf: Add wakeup_source iterator > > selftests/bpf: Add tests for wakeup_sources > > > > kernel/bpf/Makefile | 3 + > > kernel/bpf/wakeup_source_iter.c | 103 ++++++ > > tools/testing/selftests/bpf/config | 1 + > > .../bpf/prog_tests/wakeup_source_iter.c | 300 ++++++++++++++++++ > > .../selftests/bpf/progs/wakeup_source_iter.c | 80 +++++ > > 5 files changed, 487 insertions(+) > > create mode 100644 kernel/bpf/wakeup_source_iter.c > > create mode 100644 > > tools/testing/selftests/bpf/prog_tests/wakeup_source_iter.c > > create mode 100644 tools/testing/selftests/bpf/progs/wakeup_source_iter.c > > > > -- > > 2.53.0.473.g4a7958ca14-goog > > > > Hi Andrii, any thoughts on this patchset? I've addressed your > suggestion from v2 of this patchset regarding selftest, but nothing > fundamental has changed since then.
I think it's still unclear why this cannot be achieved by exploring what Andrii proposed initially in [0], i.e. by using existing primitives and adding extra kfuncs where necessary to solve bottlenecks, and I didn't see any indication where it was explored sufficiently. I think all we need is the wakeup source read_lock()/unlock() APIs as KF_ACQUIRE/KF_RELEASE kfuncs. Just need to ensure we pair each lock with unlock by passing the index, which can be an opaque value returned from the kfunc (e.g. dummy empty struct pointer encoding the index). Then you can use bpf_for() to open-code the list iteration. The iterator would become unnecessary, and everything can be done from a syscall program's BPF_PROG_RUN invocation. I didn't check how we can get the pointer to the wakeup_sources LIST_HEAD, but you could try several options (__ksym, bpf_kallsyms_lookup_name+bpf_core_cast and then walk it, or return pointer from a new kfunc and walk it using bpf_for()+bpf_core_cast()). Also, how much speed up does this really provide? It is hard to understand the motivation from the current cover letter. Is the bottleneck due to opening multiple files in sysfs? You will still have to read text and parse text from the iterator's output in your current solution. Wouldn't it be faster if you just used a syscall program, and used binary output (using a ring buffer) to stream data to user space? [0]: https://lore.kernel.org/all/CAEf4BzZv9kCAmX0Fo4kR8qh9mu5NB-wLDmNAK_R=vzcxl7v...@mail.gmail.com/ > > Thanks! > Sam >
