From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89AE021767D for ; Wed, 4 Feb 2026 09:02:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770195757; cv=none; b=pC94RIsHbYVX86mo1IF78PzGFksfUgwtFpDQ9jyi084Qg86T+VTRYOWQAzP3LpavpuJ98dnDH4NXYdRArByI71xu8ajP5BJ4aNL5WDeDebtOi5TS8/KcxXgUinpAuf24hXRmOoRTbDQq/A5xpx2W4KwASV5Uc+gb/yVfZv3NRJk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770195757; c=relaxed/simple; bh=nrXgtwtgluErA+P46xrRI8zggZuVydscpcYjuDLXiVQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MdSaXquJwxiX0HXvwZu+eHqY2w/qbXp1+rOKGOrduMS5O0njr9qUDwxlwVTQxMP4p0QV9BFWTFUrgluLJNviRlDCj+Kw6MCDGN8qem6Pb5GyLxQmLkbCpPMXJzaZR5M9eyFpzQFiUmsHx46y/rvAkz2pcCcceRpl3huvVKwpwV0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Wz3/+N1k; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Wz3/+N1k" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-435903c4040so4378928f8f.3 for ; Wed, 04 Feb 2026 01:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1770195756; x=1770800556; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=+BKvdMgbyHAEo+wOrGBnZb6vr7blKztbePG761zDzsA=; b=Wz3/+N1k6GP2myy4YWUGvO4ImAKdR8CSf7XmbXsW1UM1wXWjMKqBbAcaabbr47oglq /hpCJJYFnQc4V7+99I5Z4LAO8YzcWodbAVLzNk14aSdb3+LOvdN4UI0HUd0522G1AsZZ hWD0oZDWT9hnjhnv8W8GApoyQkaQqey649yhaE8ik3w1rUOgN9t1awYq1D7jIFfoQQGr SqrBtY98wGmelbkjjdWP5rtUxYiYJ8OsiOGYOGySV6Qm85H6NsqX7OaNdj0eLh2XIZrv GDZD1DEvKjcs4H/OX5XdyjvhygOpPRzkRQmPZPIkDVb6L10q4vjVhrPic6cEyJW5FlpH fbfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770195756; x=1770800556; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+BKvdMgbyHAEo+wOrGBnZb6vr7blKztbePG761zDzsA=; b=iSKPlbQck+SrmdNFXGxRFk1H3jeI+K7RR/36cBCGCtuuCRX2m5hOh4AkaA+eECZkEX vyoXgAmumhvuxLCWcJLdiN09+7fymYq3Pkw/zMv5z3gUFFB25MR16T3fDpsY+MmEefXb Y88zk+rREQ7PgwiTxCXxtLAaPOSyny0EUSu6pvrYvRAF3iqJx7GkWi2IFfnZ7PBLo6p6 3W89OEf7WV4krPs9NTMrmI93otsv8sJl7rnm1ZoLzk0OBHHV0K/irzEenifAnqyWMi9b V9+Wm80QoxU0egBLZF9AWf8N64YywKEP2iiAMY4XoM6uCuy7fpyY3W8pGawbEkIBpC/A IOkg== X-Forwarded-Encrypted: i=1; AJvYcCX4IVFg6cSve1u9m0lLHy8ZhRpmxqfFOC/YvYpjNhZRfXZcNLRXRHLz+XK6d3BgX6VwmGAL7qtV9Q2hw08=@vger.kernel.org X-Gm-Message-State: AOJu0YxF5F2MG2YGiGaMo6fg1kXwZxx1s20X3/BEtqQM9GXKT3+/TCgf MguKkBIkkCt+1qM5DBfEQouHal5Inc60H3M2DNs8vN3skYiVfkTR7pEKwCg+K1ubT64= X-Gm-Gg: AZuq6aJuXZMpjaIGk6GwVqhAtrDbQCst0L9ALDvGjfu370fj2whNkNu+5em02U3igC5 UxDC0JLmqDJHZDRi8E52e2zlAYDuW/W9HAb6ESBVeVDEtd4Fjd8d6PeW9cxmhAlmA4qrZxNEK6a NT0HxT77yhA1mzFRZS588uFCaY9n2acTE08uLCz1JEr138kc+W9G3XjZVlGKBox57t0GR1UyniY QpAfyyjX/OFbMQAwyt8e+2J4VsN+ioL+53WoX3xn0jXCUo3GpwKvzlv7wDy7ESpvVCE4bRiXCVm vEpUyNQp/wI2qWUPX5azsWlpokknXHsz6XTlIP17sPvqzR42jj5M8VYiBqqMRdMpeY50QSpZfrk YNdau+TicvdApeQ8AycH7NFAuSaTrlteueIN2IpSSpncNmJ3CaXYvfhvIGcR5VNPbfNGjD1YwvN bOeH/ZLP728D2nKQPidcYaPuMn X-Received: by 2002:a05:600c:34cb:b0:47e:e779:36d with SMTP id 5b1f17b1804b1-4830e96d019mr26114345e9.23.1770195755513; Wed, 04 Feb 2026 01:02:35 -0800 (PST) Received: from localhost (109-81-26-156.rct.o2.cz. [109.81.26.156]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4831088d318sm50023575e9.10.2026.02.04.01.02.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Feb 2026 01:02:34 -0800 (PST) Date: Wed, 4 Feb 2026 10:02:30 +0100 From: Michal Hocko To: Alexei Starovoitov Cc: Roman Gushchin , Matt Bobrowski , bpf , 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 Message-ID: References: <20260127024421.494929-1-roman.gushchin@linux.dev> <20260127024421.494929-11-roman.gushchin@linux.dev> <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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue 03-02-26 08:31:19, Alexei Starovoitov wrote: > On Tue, Feb 3, 2026 at 5:23 AM Michal Hocko wrote: > > > > On Mon 02-02-26 16:14:37, Roman Gushchin wrote: [...] > > > Michal, do you feel strongly about having a dedicated kfunc vs the > > > direct memory read? > > > > The reason I wanted this an explicit API is that oom states are quite > > internal part of the oom synchronization. And I would really like to > > have that completely transparent for oom policies. In other words I do > > not want to touch all potential oom policies or break them in the worst > > case just because we need to change this. So while a trivial interface > > now (and hopefully for a long time) it is really an internal thing. > > > > Do I insist? No, I do not but I would like to hear why this is a bad > > idea. > > It's a bad idea, since it doesn't address your goal. > bpf prog can access task->signal->oom_mm without kfunc just fine > and it will be doing so because performance matters and > static inline bool foo(task) > { > return task->signal->oom_mm; > } OK, so my understanding was that BPF can only use exported functionality. If those progs can access whatever they get a pointer for and than traverse down the road then this is moot from a large part. > will be inlined as 2 loads while kfunc is a function call with 6 registers > being scratched. performance is not really crucial in this context. We are OOM, couple of loads vs. registers will not make much difference. It is really more about code writers what they can/should be using. OOM is a piece of complex code with many loose ends that might not be obvious. > If anything changes and, say, oom_mm will get renamed whether > it was kfunc or not doesn't change much. progs will adopt to a new > way easily with CORE. kfuncs can also be renamed/deleted, etc. > You're thinking about kfuncs as a stable api. It's definitely not. > It's not a layer of isolation either. kfuncs are necessary only > for the cases where bpf prog cannot do it on its own. It is obviously not clear to me where that line is for BPF progs. Where is this documented? -- Michal Hocko SUSE Labs