BPF maintainer NACKs page_owner iterator series as overkill

Alexei Starovoitov has rejected a seven-patch series that would expose the kernel's page_owner memory-debug data to eBPF through a dedicated iterator pair and helper functions, calling the design overkill.

page_owner records which task allocated each page. Today that data reaches userspace only as a flat debugfs dump, so filtering by pid, cgroup, NUMA node, or stack means streaming and parsing the whole file. On large hosts that is expensive and awkward for live queries. Zhen Ni of EasyStack proposed a seq_file bpf_iter target, an open-coded iterator sharing the same walk, and kfuncs to resolve stack-depot handles and full memcg cgroup paths so a BPF program could filter and aggregate in-kernel.

Starovoitov, who maintains BPF, argued that almost none of that belongs in the kernel. A single kfunc that returns the page_owner record for a given PFN is enough; the walk, eligibility checks, and filters should live in the program via bpf_for, with range bounds supplied from userspace (for example from zoneinfo). Iterators, he wrote, exist for structures a program cannot walk on its own. A PFN is just a number.

Ni replied that both iterator surfaces are thin wrappers over one shared eligibility helper, matching BPF iterator documentation, and that stack formatting and cgroup path construction are not reachable from BPF without kernel help. Starovoitov held the NACK: the documentation describes what to do when an iterator is warranted, not that one is required here, and his sketched kfunc already covers the online-page, page_ext, and snapshot work the series duplicated.

Andrew Morton separately asked whether Ni's earlier print_mode filter series had already reduced the need for heavier machinery. Ni said that effort had led maintainers toward a BPF direction precisely to avoid ever-growing hardcoded kernel filters; Starovoitov's review now points at a much thinner shape for that direction.