On Sat, 7 Mar 2026 at 00:28, Kumar Kartikeya Dwivedi <[email protected]> wrote: > > 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.
I had a longer discussion with Paul on this. When having multiple open SRCU sections, mixing nested calls doesn't flatten the protection scopes and leads to all kinds of issues, an example of which is in [0]. That said, in this case, the verifier isn't tracking what the underlying SRCU section protects or isn't even aware of it, all it needs to ensure is that section is closed eventually, out-of-order unlocks are ok, it would just exist to allow looking at the list in a stable fashion using safe bpf_core_cast() accesses. So, I just wanted to clarify why I think this should be perfectly ok. [0]: https://www.kernel.org/pub/linux/kernel/people/paulmck/Answers/RCU/SRCUhoha.html (if you are like me, please follow the link at the bottom of [0] before feeling good about understanding the example). > 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 > >
