Re: [PATCH 1/2] block: add BPF kfuncs to read blkcg io.stat

[JP Kobryn <jp.kobryn@linux.dev>]

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.