On Fri, Jan 9, 2026 at 3:37 PM Andrii Nakryiko <[email protected]> wrote: > > On Thu, Jan 8, 2026 at 2:56 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. > > > > This series implements two types of iterators: > > 1. Standard BPF Iterator: Allows creating a BPF link to iterate over > > wakeup sources > > 2. Open-coded Iterator: Enables the use of wakeup_source iterators directly > > within BPF programs > > > > Both iterators utilize pre-existing APIs wakeup_sources_walk_* to traverse > > over the SRCU that backs the list of wakeup_sources. > > One reason to add either open-coded iterator or iterator program is > when you need to work with some kernel object (i.e., if there is some > additional API that takes that object and somehow manipulates it) or > if traversal logic is involved in terms of synchronization primitives > necessary. > > In your case neither concern seems to apply. Looking at > wakeup_sources_walk_* helpers, it's just a simple linked list > traversal and struct wakeup_source has plenty of plain data fields of > interest, if I understand correctly. You probably are not intending to > allow locking it or manipulate wakeirq, is that right? >
Correct. > So I'd say you should do this using bpf_for() generic loop and > bpf_core_cast() helper. The only problem is that wakeup_sources global > variable is static, so it's not that easy to get its memory address > (to start iteration). Maybe look into working around that first? > > pw-bot: cr > I'm thinking I'll have to drop the open-coded iterators patches in the v3 patchset, and revisit this in a later patchset when we have a clear use case for it. I'm seeing now that open-coded iterators support was added around kernel 6.6, so backwards compatibility will be nontrivial. > > > > > 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 (4): > > bpf: Add wakeup_source iterator > > bpf: Open coded BPF for wakeup_sources > > selftests/bpf: Add tests for wakeup_sources > > selftests/bpf: Open coded BPF wakeup_sources test > > > > kernel/bpf/Makefile | 3 + > > kernel/bpf/helpers.c | 3 + > > kernel/bpf/wakeup_source_iter.c | 137 ++++++++ > > .../testing/selftests/bpf/bpf_experimental.h | 5 + > > tools/testing/selftests/bpf/config | 1 + > > .../bpf/prog_tests/wakeup_source_iter.c | 323 ++++++++++++++++++ > > .../selftests/bpf/progs/wakeup_source_iter.c | 117 +++++++ > > 7 files changed, 589 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.52.0.457.g6b5491de43-goog > >
