Re: [PATCH 1/2] block: add BPF kfuncs to read blkcg io.stat
JP Kobryn <[email protected]>
| Newsgroups | org.kernel.vger.cgroups,org.kernel.vger.bpf,org.kernel.vger.linux-block,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest |
|---|---|
| Message-ID | <[email protected]> |
On 8/10/26 3:46 PM, Ziyang Men wrote: > Hi Tejun, > > Thanks for your review and suggestions! > > On Mon, Aug 10, 2026 at 10:00:55AM -1000, Tejun Heo wrote: >> Hello, >> >> On Fri, Aug 07, 2026 at 12:37:31PM -0700, Ziyang Men wrote: >>> +__bpf_kfunc struct blkcg *bpf_get_root_blkcg(void) >>> +__bpf_kfunc struct blkcg *bpf_get_blkcg(struct cgroup_subsys_state >>> *css) >>> +__bpf_kfunc void bpf_put_blkcg(struct blkcg *blkcg) >>> +__bpf_kfunc void bpf_blkcg_flush_stats(struct blkcg *blkcg) >> >> I wonder whether making the above deal with css's would make more >> sense so >> that we don't end up with per-subsystem iterators. If casting to per- >> subsys >> type is necessary, we can provide RCU protected cast kfucns. >> > > Good idea! These do nothing block specific and we already have some common > helpers for it such as the bpf_get_root_blkcg(). What is missing is a > way to get > one controller's css from a cgroup with a reference held, and the cast. So > I would add in kernel/cgroup/ > > struct cgroup_subsys_state *bpf_cgroup_css(struct cgroup *cgrp, int > ssid); > void bpf_css_release(struct cgroup_subsys_state *css); > > where the @ssid is an enum cgroup_subsys_id value. Afterwards, the only > piece for > blkcg left is: > struct blkcg *bpf_css_to_blkcg(struct cgroup_subsys_state *css); > > Note the bpf_blkcg_flush_stats may keep its current shape as it mirrors the > blkcg_print_stat() which skips the root. > > With these helpers we can also replace the existing ones in > mm/bpf_memcontrol.c as well: > bpf_get_mem_cgroup() > bpf_put_mem_cgroup() > bpf_mem_cgroup_flush_stats() > > they map onto bpf_cgroup_css() plus a bpf_css_to_memcg() cast the same way. > > Hi Roman, JP, Shakeel: Do you think it is worth applying above changes for > the memory controller as well? If you are happy with the direction I am > glad to > send the conversion as a follow-up once the generic kfuncs are in. Would > you > take it? The get/put kfuncs above use KF_ACQUIRE/RELEASE so the verifier can reject memcg access after the put. Replacing them with a generic API would call for tracking a new lifetime relationship between the css and memcg (or other derived) pointer. For generic flushing, css_rstat_flush() is already a kfunc. The memcontrol version above uses memcg_vmstats_needs_flush() for skipping as needed so that should remain intact.