Re: [PATCH 1/4 v3] cgroup: use separate rstat api for bpf programs

[JP Kobryn <inwardvessel@gmail.com>]

On 3/24/25 10:47 AM, Michal Koutný wrote:
> On Wed, Mar 19, 2025 at 03:21:47PM -0700, JP Kobryn <inwardvessel@gmail.com> wrote:
>> The rstat updated/flush API functions are exported as kfuncs so bpf
>> programs can make the same calls that in-kernel code can. Split these API
>> functions into separate in-kernel and bpf versions. Function signatures
>> remain unchanged. The kfuncs are named with the prefix "bpf_". This
>> non-functional change allows for future commits which will modify the
>> signature of the in-kernel API without impacting bpf call sites. The
>> implementations of the kfuncs serve as adapters to the in-kernel API.
> 
> This made me look up
> https://docs.kernel.org/bpf/kfuncs.html#bpf-kfunc-lifecycle-expectations
> 
> The series reworks existing kfuncs anyway, is it necessary to have the
> bpf_ versions? The semantics is changed too from base+all subsystems
> flush to only base flush (bpf_rstat_flush()).

This patch was done based on some conversation in v2 around what to do
with the kfuncs (bottom of [0]). It's true the kfunc API deviates from
flush-specific-subsystem approach. Dropping this patch is fine by me and
I assume it would be ok with Yosry (based on comments at end of [0]),
but I'll wait and see if he has any input.

[0] https://lore.kernel.org/all/Z8IIxUdRpqxZyIHO@google.com/

> 
> I'd perhaps do the changes freely w/out taking kfuncs into account and
> then add possible reconstructive patches towards the end of the series.
> (I'm not unsure whether the modified btf_type_tag_percpu.c selftest
> survives the latest unionization of base stats.)
> 
> 
> Michal