public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hao Ge <hao.ge@linux.dev>
To: Matt Bobrowski <mattbobrowski@google.com>,
	Roman Gushchin <roman.gushchin@linux.dev>
Cc: bpf@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	JP Kobryn <inwardvessel@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Suren Baghdasaryan <surenb@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH bpf-next v3 08/17] mm: introduce bpf_oom_kill_process() bpf kfunc
Date: Wed, 29 Apr 2026 12:34:09 +0800	[thread overview]
Message-ID: <7b17c0c8-253f-4755-a324-1132cd3c0921@linux.dev> (raw)
In-Reply-To: <aYAsxRI2JGU9KCeO@google.com>


On 2026/2/2 12:49, Matt Bobrowski wrote:
> On Mon, Jan 26, 2026 at 06:44:11PM -0800, Roman Gushchin wrote:
>> Introduce bpf_oom_kill_process() bpf kfunc, which is supposed
>> to be used by BPF OOM programs. It allows to kill a process
>> in exactly the same way the OOM killer does: using the OOM reaper,
>> bumping corresponding memcg and global statistics, respecting
>> memory.oom.group etc.
>>
>> On success, it sets the oom_control's bpf_memory_freed field to true,
>> enabling the bpf program to bypass the kernel OOM killer.
>>
>> Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
>> ---
>>   mm/oom_kill.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 80 insertions(+)
>>
>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
>> index 44bbcf033804..09897597907f 100644
>> --- a/mm/oom_kill.c
>> +++ b/mm/oom_kill.c
>> @@ -46,6 +46,7 @@
>>   #include <linux/cred.h>
>>   #include <linux/nmi.h>
>>   #include <linux/bpf_oom.h>
>> +#include <linux/btf.h>
>>   
>>   #include <asm/tlb.h>
>>   #include "internal.h"
>> @@ -1290,3 +1291,82 @@ SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
>>   	return -ENOSYS;
>>   #endif /* CONFIG_MMU */
>>   }
>> +
>> +#ifdef CONFIG_BPF_SYSCALL
>> +
>> +__bpf_kfunc_start_defs();
>> +/**
>> + * bpf_oom_kill_process - Kill a process as OOM killer
>> + * @oc: pointer to oom_control structure, describes OOM context
>> + * @task: task to be killed
>> + * @message__str: message to print in dmesg
>> + *
>> + * Kill a process in a way similar to the kernel OOM killer.
>> + * This means dump the necessary information to dmesg, adjust memcg
>> + * statistics, leverage the oom reaper, respect memory.oom.group etc.
>> + *
>> + * bpf_oom_kill_process() marks the forward progress by setting
>> + * oc->bpf_memory_freed. If the progress was made, the bpf program
>> + * is free to decide if the kernel oom killer should be invoked.
>> + * Otherwise it's enforced, so that a bad bpf program can't
>> + * deadlock the machine on memory.
>> + */
>> +__bpf_kfunc int bpf_oom_kill_process(struct oom_control *oc,
>> +				     struct task_struct *task,
>> +				     const char *message__str)
>> +{
>> +	if (oom_unkillable_task(task))
>> +		return -EPERM;
>> +
>> +	if (task->signal->oom_score_adj == OOM_SCORE_ADJ_MIN)
>> +		return -EINVAL;
Hi Matt and Roman
> task->signal->oom_score_adj == OOM_SCORE_ADJ_MIN is also
> representative of an unkillable task, so why not fold this up into the
> above conditional? Also, why not bother checking states like
> mm_flags_test(MMF_OOM_SKIP, task->mm) and in_vfork() here too?
>
> In all fairness I'm a little surprised about constraints like
> task->signal->oom_score_adj == OOM_SCORE_ADJ_MIN being enforced
> here. You could argue that the whole purpose of BPF OOM is such that
> you can implement your own victim selection algorithms entirely in BPF
> using your own set of heuristics and what not without needing to
> strictly respect properties like oom_score_adj.

Just my 2 cents — historically many users rely on setting oom_score_adj 
to OOM_SCORE_ADJ_MIN to protect their critical processes.

If we don't check this here and a custom BPF program happens to forget 
it, users would be quite surprised to find their most important

processes killed despite having explicitly marked them as protected.

So this really comes down to a priority question: when a custom BPF OOM 
policy decides to kill a process that the admin has explicitly

marked as protected via OOM_SCORE_ADJ_MIN, which one should take 
precedence?


> In any case, I think we should at least clearly document such
> constraints.

Fully agree. We need thorough documentation on what 
bpf_oom_kill_process() enforces on the kernel side,

so that custom BPF programs know exactly what's already handled and what 
additional checks they may

need to perform depending on their use case.


Thanks

Best regards.
Hao

>> +	/* paired with put_task_struct() in oom_kill_process() */
>> +	get_task_struct(task);
>> +
>> +	oc->chosen = task;
>> +
>> +	oom_kill_process(oc, message__str);
>> +
>> +	oc->chosen = NULL;
>> +	oc->bpf_memory_freed = true;
>> +
>> +	return 0;
>> +}
>> +
>> +__bpf_kfunc_end_defs();
>> +
>> +BTF_KFUNCS_START(bpf_oom_kfuncs)
>> +BTF_ID_FLAGS(func, bpf_oom_kill_process, KF_SLEEPABLE)
>> +BTF_KFUNCS_END(bpf_oom_kfuncs)
>> +
>> +BTF_ID_LIST_SINGLE(bpf_oom_ops_ids, struct, bpf_oom_ops)
>> +
>> +static int bpf_oom_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id)
>> +{
>> +	if (prog->type != BPF_PROG_TYPE_STRUCT_OPS ||
>> +	    prog->aux->attach_btf_id != bpf_oom_ops_ids[0])
>> +		return -EACCES;
>> +	return 0;
>> +}
>> +
>> +static const struct btf_kfunc_id_set bpf_oom_kfunc_set = {
>> +	.owner          = THIS_MODULE,
>> +	.set            = &bpf_oom_kfuncs,
>> +	.filter         = bpf_oom_kfunc_filter,
>> +};
>> +
>> +static int __init bpf_oom_init(void)
>> +{
>> +	int err;
>> +
>> +	err = register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS,
>> +					&bpf_oom_kfunc_set);
>> +	if (err)
>> +		pr_warn("error while registering bpf oom kfuncs: %d", err);
>> +
>> +	return err;
>> +}
>> +late_initcall(bpf_oom_init);
>> +
>> +#endif
>> -- 
>> 2.52.0
>>

  reply	other threads:[~2026-04-29  4:35 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27  2:44 [PATCH bpf-next v3 00/17] mm: BPF OOM Roman Gushchin
2026-01-27  2:44 ` [PATCH bpf-next v3 01/17] bpf: move bpf_struct_ops_link into bpf.h Roman Gushchin
2026-01-27  5:50   ` Yafang Shao
2026-01-28 11:28   ` Matt Bobrowski
2026-01-27  2:44 ` [PATCH bpf-next v3 02/17] bpf: allow attaching struct_ops to cgroups Roman Gushchin
2026-01-27  3:08   ` bot+bpf-ci
2026-01-27  5:49   ` Yafang Shao
2026-01-28  3:10   ` Josh Don
2026-01-28 18:52     ` Roman Gushchin
2026-01-28 11:25   ` Matt Bobrowski
2026-01-28 19:18     ` Roman Gushchin
2026-01-27  2:44 ` [PATCH bpf-next v3 03/17] libbpf: fix return value on memory allocation failure Roman Gushchin
2026-01-27  5:52   ` Yafang Shao
2026-01-27  2:44 ` [PATCH bpf-next v3 04/17] libbpf: introduce bpf_map__attach_struct_ops_opts() Roman Gushchin
2026-01-27  3:08   ` bot+bpf-ci
2026-01-27  2:44 ` [PATCH bpf-next v3 05/17] bpf: mark struct oom_control's memcg field as TRUSTED_OR_NULL Roman Gushchin
2026-01-27  6:06   ` Yafang Shao
2026-02-02  4:56   ` Matt Bobrowski
2026-01-27  2:44 ` [PATCH bpf-next v3 06/17] mm: define mem_cgroup_get_from_ino() outside of CONFIG_SHRINKER_DEBUG Roman Gushchin
2026-01-27  6:12   ` Yafang Shao
2026-02-02  3:50   ` Shakeel Butt
2026-03-26  8:17   ` teawater
2026-01-27  2:44 ` [PATCH bpf-next v3 07/17] mm: introduce BPF OOM struct ops Roman Gushchin
2026-01-27  9:38   ` Michal Hocko
2026-01-27 21:12     ` Roman Gushchin
2026-01-28  8:00       ` Michal Hocko
2026-01-28 18:44         ` Roman Gushchin
2026-02-02  4:06       ` Matt Bobrowski
2026-01-28  3:26   ` Josh Don
2026-01-28 19:03     ` Roman Gushchin
2026-01-28 11:19   ` Michal Hocko
2026-01-28 18:53     ` Roman Gushchin
2026-01-29 21:00   ` Martin KaFai Lau
2026-01-30 23:29     ` Roman Gushchin
2026-02-02 20:27       ` Martin KaFai Lau
2026-01-27  2:44 ` [PATCH bpf-next v3 08/17] mm: introduce bpf_oom_kill_process() bpf kfunc Roman Gushchin
2026-01-27 20:21   ` Martin KaFai Lau
2026-01-27 20:47     ` Roman Gushchin
2026-02-02  4:49   ` Matt Bobrowski
2026-04-29  4:34     ` Hao Ge [this message]
2026-01-27  2:44 ` [PATCH bpf-next v3 09/17] mm: introduce bpf_out_of_memory() BPF kfunc Roman Gushchin
2026-01-28 20:21   ` Matt Bobrowski
2026-01-27  2:44 ` [PATCH bpf-next v3 10/17] mm: introduce bpf_task_is_oom_victim() kfunc Roman Gushchin
2026-02-02  5:39   ` Matt Bobrowski
2026-02-02 17:30     ` Alexei Starovoitov
2026-02-03  0:14       ` Roman Gushchin
2026-02-03 13:23         ` Michal Hocko
2026-02-03 16:31           ` Alexei Starovoitov
2026-02-04  9:02             ` Michal Hocko
2026-02-05  0:12               ` Alexei Starovoitov
2026-01-27  2:44 ` [PATCH bpf-next v3 11/17] bpf: selftests: introduce read_cgroup_file() helper Roman Gushchin
2026-01-27  3:08   ` bot+bpf-ci
2026-01-27  2:44 ` [PATCH bpf-next v3 12/17] bpf: selftests: BPF OOM struct ops test Roman Gushchin
2026-01-27  2:44 ` [PATCH bpf-next v3 13/17] sched: psi: add a trace point to psi_avgs_work() Roman Gushchin
2026-01-27  2:44 ` [PATCH bpf-next v3 14/17] sched: psi: add cgroup_id field to psi_group structure Roman Gushchin
2026-01-27  2:44 ` [PATCH bpf-next v3 15/17] bpf: allow calling bpf_out_of_memory() from a PSI tracepoint Roman Gushchin
2026-01-27  9:02 ` [PATCH bpf-next v3 00/17] mm: BPF OOM Michal Hocko
2026-01-27 21:01   ` Roman Gushchin
2026-01-28  8:06     ` Michal Hocko
2026-01-28 16:59       ` Alexei Starovoitov
2026-01-28 18:23         ` Roman Gushchin
2026-01-28 18:53           ` Alexei Starovoitov
2026-02-02  3:26         ` Matt Bobrowski
2026-02-02 17:50           ` Alexei Starovoitov
2026-02-04 23:52             ` Matt Bobrowski

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=7b17c0c8-253f-4755-a324-1132cd3c0921@linux.dev \
    --to=hao.ge@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=inwardvessel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mattbobrowski@google.com \
    --cc=mhocko@suse.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --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