From: Suren Baghdasaryan <surenb@google.com>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: linux-mm@kvack.org, bpf@vger.kernel.org,
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 06/14] mm: introduce bpf_out_of_memory() bpf kfunc
Date: Mon, 18 Aug 2025 21:09:24 -0700 [thread overview]
Message-ID: <CAJuCfpHTtLQR0NpsbFytaOdEc0KqNv6PxVpxNetYD6Ce4sY9UQ@mail.gmail.com> (raw)
In-Reply-To: <20250818170136.209169-7-roman.gushchin@linux.dev>
On Mon, Aug 18, 2025 at 10:02 AM Roman Gushchin
<roman.gushchin@linux.dev> wrote:
>
> Introduce bpf_out_of_memory() bpf kfunc, which allows to declare
> an out of memory events and trigger the corresponding kernel OOM
> handling mechanism.
>
> It takes a trusted memcg pointer (or NULL for system-wide OOMs)
> as an argument, as well as the page order.
>
> If the wait_on_oom_lock argument is not set, only one OOM can be
> declared and handled in the system at once, so if the function is
> called in parallel to another OOM handling, it bails out with -EBUSY.
> This mode is suited for global OOM's: any concurrent OOMs will likely
> do the job and release some memory. In a blocking mode (which is
> suited for memcg OOMs) the execution will wait on the oom_lock mutex.
>
> The function is declared as sleepable. It guarantees that it won't
> be called from an atomic context. It's required by the OOM handling
> code, which is not guaranteed to work in a non-blocking context.
>
> Handling of a memcg OOM almost always requires taking of the
> css_set_lock spinlock. The fact that bpf_out_of_memory() is sleepable
> also guarantees that it can't be called with acquired css_set_lock,
> so the kernel can't deadlock on it.
>
> Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
> ---
> mm/oom_kill.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 25fc5e744e27..df409f0fac45 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -1324,10 +1324,55 @@ __bpf_kfunc int bpf_oom_kill_process(struct oom_control *oc,
> return 0;
> }
>
> +/**
> + * bpf_out_of_memory - declare Out Of Memory state and invoke OOM killer
> + * @memcg__nullable: memcg or NULL for system-wide OOMs
> + * @order: order of page which wasn't allocated
> + * @wait_on_oom_lock: if true, block on oom_lock
> + * @constraint_text__nullable: custom constraint description for the OOM report
> + *
> + * Declares the Out Of Memory state and invokes the OOM killer.
> + *
> + * OOM handlers are synchronized using the oom_lock mutex. If wait_on_oom_lock
> + * is true, the function will wait on it. Otherwise it bails out with -EBUSY
> + * if oom_lock is contended.
> + *
> + * Generally it's advised to pass wait_on_oom_lock=true for global OOMs
> + * and wait_on_oom_lock=false for memcg-scoped OOMs.
From the changelog description I was under impression that it's vice
versa, for global OOMs you would not block (wait_on_oom_lock=false),
for memcg ones you would (wait_on_oom_lock=true).
> + *
> + * Returns 1 if the forward progress was achieved and some memory was freed.
> + * Returns a negative value if an error has been occurred.
s/has been occurred/has occurred or occured
> + */
> +__bpf_kfunc int bpf_out_of_memory(struct mem_cgroup *memcg__nullable,
> + int order, bool wait_on_oom_lock)
> +{
> + struct oom_control oc = {
> + .memcg = memcg__nullable,
> + .order = order,
> + };
> + int ret;
> +
> + if (oc.order < 0 || oc.order > MAX_PAGE_ORDER)
> + return -EINVAL;
> +
> + if (wait_on_oom_lock) {
> + ret = mutex_lock_killable(&oom_lock);
> + if (ret)
> + return ret;
> + } else if (!mutex_trylock(&oom_lock))
> + return -EBUSY;
> +
> + ret = out_of_memory(&oc);
> +
> + mutex_unlock(&oom_lock);
> + return ret;
> +}
> +
> __bpf_kfunc_end_defs();
>
> BTF_KFUNCS_START(bpf_oom_kfuncs)
> BTF_ID_FLAGS(func, bpf_oom_kill_process, KF_SLEEPABLE | KF_TRUSTED_ARGS)
> +BTF_ID_FLAGS(func, bpf_out_of_memory, KF_SLEEPABLE | KF_TRUSTED_ARGS)
> BTF_KFUNCS_END(bpf_oom_kfuncs)
>
> static const struct btf_kfunc_id_set bpf_oom_kfunc_set = {
> --
> 2.50.1
>
next prev parent reply other threads:[~2025-08-19 4:09 UTC|newest]
Thread overview: 69+ 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-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 [this message]
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
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=CAJuCfpHTtLQR0NpsbFytaOdEc0KqNv6PxVpxNetYD6Ce4sY9UQ@mail.gmail.com \
--to=surenb@google.com \
--cc=akpm@linux-foundation.org \
--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=roman.gushchin@linux.dev \
--cc=song@kernel.org \
/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).