From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B947EC001DE for ; Thu, 10 Aug 2023 19:41:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235762AbjHJTlO (ORCPT ); Thu, 10 Aug 2023 15:41:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233486AbjHJTlM (ORCPT ); Thu, 10 Aug 2023 15:41:12 -0400 Received: from out-110.mta1.migadu.com (out-110.mta1.migadu.com [95.215.58.110]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5C4D26B5 for ; Thu, 10 Aug 2023 12:41:10 -0700 (PDT) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1691696468; 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=OuDx6q87jGoCwsecy09MqUn126nk87pBh26c1SpaUZI=; b=EyIqYMe+6RnnpEVKI1DDmD/DL9g9mqschLBHCfLPeH6sJI8V8oI6p18NmddlVUh3zGrgdw poEHB80/OafLc+5Z6Lp9U0lr8Q2o7wCEKcA1LyrzheoJx3KQJ3/Sg87iEIFDJiR0dvde6F Iq5XbQuMFFQkt0xZcte/W+q0kmgGJSs= Date: Thu, 10 Aug 2023 12:41:01 -0700 MIME-Version: 1.0 Subject: Re: [RFC PATCH 1/2] mm, oom: Introduce bpf_select_task Content-Language: en-US To: Michal Hocko , Roman Gushchin Cc: Chuyi Zhou , hannes@cmpxchg.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, muchun.song@linux.dev, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, wuyun.abel@bytedance.com, robin.lu@bytedance.com References: <20230804093804.47039-1-zhouchuyi@bytedance.com> <20230804093804.47039-2-zhouchuyi@bytedance.com> <866462cf-6045-6239-6e27-45a733aa7daa@bytedance.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>> First, I'm a bit concerned about implicit restrictions we apply to bpf programs >>>> which will be executed potentially thousands times under a very heavy memory >>>> pressure. We will need to make sure that they don't allocate (much) memory, don't >>>> take any locks which might deadlock with other memory allocations etc. >>>> It will potentially require hard restrictions on what these programs can and can't >>>> do and this is something that the bpf community will have to maintain long-term. >>> >>> Right, BPF callbacks operating under OOM situations will be really >>> constrained but this is more or less by definition. Isn't it? >> >> What do you mean? > > Callbacks cannot depend on any direct or indirect memory allocations. > Dependencies on any sleeping locks (again directly or indirectly) is not > allowed just to name the most important ones. > >> In general, the bpf community is trying to make it as generic as possible and >> adding new and new features. Bpf programs are not as constrained as they were >> when it's all started. bpf supports different running context. For example, only non-sleepable bpf prog is allowed to run at the NIC driver. A sleepable bpf prog is only allowed to run at some bpf_lsm hooks that is known to be safe to call blocking bpf-helper/kfunc. From the bpf side, it ensures a non-sleepable bpf prog cannot do things that may block. fwiw, Dave has recently proposed something for iterating the task vma (https://lore.kernel.org/bpf/20230810183513.684836-4-davemarchevsky@fb.com/). Potentially, a similar iterator can be created for a bpf program to iterate cgroups and tasks.