From: Roman Gushchin <roman.gushchin@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: linux-mm@kvack.org, bpf@vger.kernel.org,
Suren Baghdasaryan <surenb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.com>,
David Rientjes <rientjes@google.com>,
Matt Bobrowski <mattbobrowski@google.com>,
Song Liu <song@kernel.org>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 13/14] sched: psi: implement bpf_psi_create_trigger() kfunc
Date: Wed, 20 Aug 2025 17:36:05 -0700 [thread overview]
Message-ID: <87ect5lde2.fsf@linux.dev> (raw)
In-Reply-To: <CAEf4BzaSLWB1xpCjX35oxg2ySvvgRvEmQ01PtXv+xEz-Zkz07w@mail.gmail.com> (Andrii Nakryiko's message of "Wed, 20 Aug 2025 13:30:43 -0700")
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Mon, Aug 18, 2025 at 10:06 AM Roman Gushchin
> <roman.gushchin@linux.dev> wrote:
>>
>> Implement a new bpf_psi_create_trigger() bpf kfunc, which allows
>> to create new psi triggers and attach them to cgroups or be
>> system-wide.
>>
>> Created triggers will exist until the struct ops is loaded and
>> if they are attached to a cgroup until the cgroup exists.
>>
>> Due to a limitation of 5 arguments, the resource type and the "full"
>> bit are squeezed into a single u32.
>>
>> Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
>> ---
>> kernel/sched/bpf_psi.c | 84 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 84 insertions(+)
>>
>> diff --git a/kernel/sched/bpf_psi.c b/kernel/sched/bpf_psi.c
>> index 2ea9d7276b21..94b684221708 100644
>> --- a/kernel/sched/bpf_psi.c
>> +++ b/kernel/sched/bpf_psi.c
>> @@ -156,6 +156,83 @@ static const struct bpf_verifier_ops bpf_psi_verifier_ops = {
>> .is_valid_access = bpf_psi_ops_is_valid_access,
>> };
>>
>> +__bpf_kfunc_start_defs();
>> +
>> +/**
>> + * bpf_psi_create_trigger - Create a PSI trigger
>> + * @bpf_psi: bpf_psi struct to attach the trigger to
>> + * @cgroup_id: cgroup Id to attach the trigger; 0 for system-wide scope
>> + * @resource: resource to monitor (PSI_MEM, PSI_IO, etc) and the full bit.
>> + * @threshold_us: threshold in us
>> + * @window_us: window in us
>> + *
>> + * Creates a PSI trigger and attached is to bpf_psi. The trigger will be
>> + * active unless bpf struct ops is unloaded or the corresponding cgroup
>> + * is deleted.
>> + *
>> + * Resource's most significant bit encodes whether "some" or "full"
>> + * PSI state should be tracked.
>> + *
>> + * Returns 0 on success and the error code on failure.
>> + */
>> +__bpf_kfunc int bpf_psi_create_trigger(struct bpf_psi *bpf_psi,
>> + u64 cgroup_id, u32 resource,
>> + u32 threshold_us, u32 window_us)
>> +{
>> + enum psi_res res = resource & ~BPF_PSI_FULL;
>> + bool full = resource & BPF_PSI_FULL;
>> + struct psi_trigger_params params;
>> + struct cgroup *cgroup __maybe_unused = NULL;
>> + struct psi_group *group;
>> + struct psi_trigger *t;
>> + int ret = 0;
>> +
>> + if (res >= NR_PSI_RESOURCES)
>> + return -EINVAL;
>> +
>> +#ifdef CONFIG_CGROUPS
>> + if (cgroup_id) {
>> + cgroup = cgroup_get_from_id(cgroup_id);
>> + if (IS_ERR_OR_NULL(cgroup))
>> + return PTR_ERR(cgroup);
>> +
>> + group = cgroup_psi(cgroup);
>> + } else
>> +#endif
>> + group = &psi_system;
>
> just a drive-by comment while skimming through the patch set: can't
> you use IS_ENABLED(CONFIG_CGROUPS) and have a proper if/else with
> proper {} ?
Fixed.
It required defining cgroup_get_from_id() and cgroup_psi()
for !CONFIG_CGROUPS, but I agree, it's much better.
Thanks
>
>> +
>> + params.type = PSI_BPF;
>> + params.bpf_psi = bpf_psi;
>> + params.privileged = capable(CAP_SYS_RESOURCE);
>> + params.res = res;
>> + params.full = full;
>> + params.threshold_us = threshold_us;
>> + params.window_us = window_us;
>> +
>> + t = psi_trigger_create(group, ¶ms);
>> + if (IS_ERR(t))
>> + ret = PTR_ERR(t);
>> + else
>> + t->cgroup_id = cgroup_id;
>> +
>> +#ifdef CONFIG_CGROUPS
>> + if (cgroup)
>> + cgroup_put(cgroup);
>> +#endif
>> +
>> + return ret;
>> +}
>> +__bpf_kfunc_end_defs();
>> +
>> +BTF_KFUNCS_START(bpf_psi_kfuncs)
>> +BTF_ID_FLAGS(func, bpf_psi_create_trigger, KF_TRUSTED_ARGS)
>> +BTF_KFUNCS_END(bpf_psi_kfuncs)
>> +
>> +static const struct btf_kfunc_id_set bpf_psi_kfunc_set = {
>> + .owner = THIS_MODULE,
>> + .set = &bpf_psi_kfuncs,
>> +};
>> +
>> static int bpf_psi_ops_reg(void *kdata, struct bpf_link *link)
>> {
>> struct bpf_psi_ops *ops = kdata;
>> @@ -238,6 +315,13 @@ static int __init bpf_psi_struct_ops_init(void)
>> if (!bpf_psi_wq)
>> return -ENOMEM;
>>
>> + err = register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS,
>> + &bpf_psi_kfunc_set);
>
> would this make kfunc callable from any struct_ops, not just this psi
> one?
It will. Idk how big of a problem it is, given that the caller needs
a trusted reference to bpf_psi. Also, is there a simple way to constrain
it? Wdyt?
next prev parent reply other threads:[~2025-08-21 0:36 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 17:01 [PATCH v1 00/14] mm: BPF OOM Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 01/14] mm: introduce bpf struct ops for OOM handling Roman Gushchin
2025-08-19 4:09 ` Suren Baghdasaryan
2025-08-19 20:06 ` Roman Gushchin
2025-08-20 19:34 ` Suren Baghdasaryan
2025-08-20 19:52 ` Roman Gushchin
2025-08-20 20:01 ` Suren Baghdasaryan
2025-08-26 16:23 ` Amery Hung
2025-08-20 11:28 ` Kumar Kartikeya Dwivedi
2025-08-21 0:24 ` Roman Gushchin
2025-08-21 0:36 ` Kumar Kartikeya Dwivedi
2025-08-21 2:22 ` Roman Gushchin
2025-08-21 15:54 ` Suren Baghdasaryan
2025-08-22 19:27 ` Martin KaFai Lau
2025-08-25 17:00 ` Roman Gushchin
2025-08-26 18:01 ` Martin KaFai Lau
2025-08-26 19:52 ` Alexei Starovoitov
2025-08-27 18:28 ` Roman Gushchin
2025-09-02 17:31 ` Roman Gushchin
2025-09-02 22:30 ` Martin KaFai Lau
2025-09-02 23:36 ` Roman Gushchin
2025-09-03 0:29 ` Tejun Heo
2025-09-03 23:30 ` Roman Gushchin
2025-09-04 6:39 ` Tejun Heo
2025-09-04 14:32 ` Roman Gushchin
2025-09-04 16:26 ` Alexei Starovoitov
2025-09-04 16:58 ` Tejun Heo
2025-08-26 16:56 ` Amery Hung
2025-08-18 17:01 ` [PATCH v1 02/14] bpf: mark struct oom_control's memcg field as TRUSTED_OR_NULL Roman Gushchin
2025-08-20 9:17 ` Kumar Kartikeya Dwivedi
2025-08-20 22:32 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 03/14] mm: introduce bpf_oom_kill_process() bpf kfunc Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 04/14] mm: introduce bpf kfuncs to deal with memcg pointers Roman Gushchin
2025-08-20 9:21 ` Kumar Kartikeya Dwivedi
2025-08-20 22:43 ` Roman Gushchin
2025-08-20 23:33 ` Kumar Kartikeya Dwivedi
2025-08-18 17:01 ` [PATCH v1 05/14] mm: introduce bpf_get_root_mem_cgroup() bpf kfunc Roman Gushchin
2025-08-20 9:25 ` Kumar Kartikeya Dwivedi
2025-08-20 22:45 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 06/14] mm: introduce bpf_out_of_memory() " Roman Gushchin
2025-08-19 4:09 ` Suren Baghdasaryan
2025-08-19 20:16 ` Roman Gushchin
2025-08-20 9:34 ` Kumar Kartikeya Dwivedi
2025-08-20 22:59 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 07/14] mm: allow specifying custom oom constraint for bpf triggers Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 08/14] mm: introduce bpf_task_is_oom_victim() kfunc Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 09/14] bpf: selftests: introduce read_cgroup_file() helper Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 10/14] bpf: selftests: bpf OOM handler test Roman Gushchin
2025-08-20 9:33 ` Kumar Kartikeya Dwivedi
2025-08-20 22:49 ` Roman Gushchin
2025-08-20 20:23 ` Andrii Nakryiko
2025-08-21 0:10 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 11/14] sched: psi: refactor psi_trigger_create() Roman Gushchin
2025-08-19 4:09 ` Suren Baghdasaryan
2025-08-19 20:28 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 12/14] sched: psi: implement psi trigger handling using bpf Roman Gushchin
2025-08-19 4:11 ` Suren Baghdasaryan
2025-08-19 22:31 ` Roman Gushchin
2025-08-19 23:31 ` Roman Gushchin
2025-08-20 23:56 ` Suren Baghdasaryan
2025-08-26 17:03 ` Amery Hung
2025-08-18 17:01 ` [PATCH v1 13/14] sched: psi: implement bpf_psi_create_trigger() kfunc Roman Gushchin
2025-08-20 20:30 ` Andrii Nakryiko
2025-08-21 0:36 ` Roman Gushchin [this message]
2025-08-22 19:13 ` Andrii Nakryiko
2025-08-22 19:57 ` Martin KaFai Lau
2025-08-25 16:56 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 14/14] bpf: selftests: psi struct ops test Roman Gushchin
2025-08-19 4:08 ` [PATCH v1 00/14] mm: BPF OOM Suren Baghdasaryan
2025-08-19 19:52 ` Roman Gushchin
2025-08-20 21:06 ` Shakeel Butt
2025-08-21 0:01 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ect5lde2.fsf@linux.dev \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mattbobrowski@google.com \
--cc=memxor@gmail.com \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
--cc=song@kernel.org \
--cc=surenb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).