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

JP Kobryn <[email protected]>
Newsgroups org.kernel.vger.linux-block,org.kernel.vger.bpf,org.kernel.vger.cgroups,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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.