From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67A0C134AB for ; Tue, 3 Feb 2026 00:14:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770077698; cv=none; b=eVe6kFTayzsv8SyPkfdzmYE3PHZZr1QHt+nv77mkgiNlN4pghRsfasZSheWbHzGaRAqjctuy1cwVCz7PYtx440XrF8w9AD6PSJwD+hLwdnGzFS0Vycp6ONyxzRZbf/BT/6nD17fU+bLBTSP9xNFXjp5sSlrWON0q2rmYt0WOEds= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770077698; c=relaxed/simple; bh=Y28HJY0iodlcCHCfRKfscVKtonnBBi5sgfeq5IYe6QQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=JjOv9R5FxaZPZgO89i8qqKcQYvKBvzyC8KJ8SedWZMxrnaQ53CtWG/+MrklF12zBHbxbHHpP30qY/1I9cQ5lkgUfaYvX+8sHMdiKo4JAVoELU2pDMR8rEvhQ3MJ6UwJGiEj+JcZPFmffveI7RZE8/bPX1VqHUJHup8BOV8lts3o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=spFvYM5S; arc=none smtp.client-ip=91.218.175.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="spFvYM5S" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770077684; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UL5TkTKpwfsk57GsEmn4YJixM6/oQfn+MbPgW31S17c=; b=spFvYM5SuR1aK33Y9Zg7Cn9Xqh/rBPTDdvWHRoUiFbG0+KEXd75LEfzQmvuXRAP0CEMz74 3OTta24r/6f555bLCbR79g70lZ2gIrFcrmQ6HQs8FkOmG6Ttzq3obI4umAEhraTtmKL+Om y2jvsjD0kO2WoqE56etQ/rIYmN1/njA= From: Roman Gushchin To: Alexei Starovoitov , Michal Hocko Cc: Matt Bobrowski , bpf , Michal Hocko , Alexei Starovoitov , Shakeel Butt , JP Kobryn , LKML , linux-mm , Suren Baghdasaryan , Johannes Weiner , Andrew Morton Subject: Re: [PATCH bpf-next v3 10/17] mm: introduce bpf_task_is_oom_victim() kfunc In-Reply-To: (Alexei Starovoitov's message of "Mon, 2 Feb 2026 09:30:23 -0800") References: <20260127024421.494929-1-roman.gushchin@linux.dev> <20260127024421.494929-11-roman.gushchin@linux.dev> Date: Mon, 02 Feb 2026 16:14:37 -0800 Message-ID: <87jywuwumq.fsf@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Alexei Starovoitov writes: > On Sun, Feb 1, 2026 at 9:39=E2=80=AFPM Matt Bobrowski wrote: >> >> On Mon, Jan 26, 2026 at 06:44:13PM -0800, Roman Gushchin wrote: >> > Export tsk_is_oom_victim() helper as a BPF kfunc. >> > It's very useful to avoid redundant oom kills. >> > >> > Signed-off-by: Roman Gushchin >> > Suggested-by: Michal Hocko >> > --- >> > mm/oom_kill.c | 14 ++++++++++++++ >> > 1 file changed, 14 insertions(+) >> > >> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c >> > index 8f63a370b8f5..53f9f9674658 100644 >> > --- a/mm/oom_kill.c >> > +++ b/mm/oom_kill.c >> > @@ -1381,10 +1381,24 @@ __bpf_kfunc int bpf_out_of_memory(struct mem_c= group *memcg__nullable, >> > return ret; >> > } >> > >> > +/** >> > + * bpf_task_is_oom_victim - Check if the task has been marked as an O= OM victim >> > + * @task: task to check >> > + * >> > + * Returns true if the task has been previously selected by the OOM k= iller >> > + * to be killed. It's expected that the task will be destroyed soon a= nd some >> > + * memory will be freed, so maybe no additional actions required. >> > + */ >> > +__bpf_kfunc bool bpf_task_is_oom_victim(struct task_struct *task) >> > +{ >> > + return tsk_is_oom_victim(task); >> > +} >> >> Why not just do a direct memory read (i.e., task->signal->oom_mm) >> within the BPF program? I'm not quite convinced that a BPF kfunc >> wrapper for something like tsk_is_oom_victim() is warranted as you can >> literally achieve the same semantics without one. > > +1 > there is no need for this kfunc. It was explicitly asked by Michal Hocko, who is (co)maintaining the oom code. I don't have a strong opinion here. I agree that it can be easily open-coded without a kfunc, but at the same time the cost of having an extra kfunc is not high and it makes the API more consistent. Michal, do you feel strongly about having a dedicated kfunc vs the direct memory read?