From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (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 D88D842F718 for ; Mon, 24 Aug 2026 13:55:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787579734; cv=none; b=CyTjx21TQtFvsUWlvLv77SybWMTf+7DAXXHhGZ2onvjxeJ3suy62O2tARX080Lrnso/lHYvUxWQ8kuQt5dhkO5lM39+P/KMt3Cevg4dy3jvKWxEGVHOyym4zro8g7R0OXGXdTazVGyb169CGRTQGeF2qxN+lMFrUqJnOHkQDCuw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787579734; c=relaxed/simple; bh=AtV5dw9gRgzyoEMLu4aQ6z8qH/ZAjeT6K0W7X0N0QpE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=L9aQ7wOZBmvrhDzBOfXnV/BHWD3uPXTZ6GEJ3Dd/PRF3gSM28IO3MKWG3DAv6eaeUfp4lj0o8i1IztUl1om5XOfZh56SNvLPkYarKL4VGTQ+iIr7MJP8ZVtKDIkU2uUFVSDAmeOhcgOMBbX1mpxr6trX/6x8sU0UqppyGlPMKVs= 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=Gk3oVLNd; arc=none smtp.client-ip=209.85.208.48 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="Gk3oVLNd" Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-6a082b3671fso5723542a12.3 for ; Mon, 24 Aug 2026 06:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787579731; x=1788184531; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=CTafZFi/HQ0yZlxsyK+vRPH1tJjqwxxSL7Z2p9md19o=; b=Gk3oVLNdg9sPcTeTPaOI0tht4nhck5axKM1DeQuNL18EmW+J9jhndSWdbFo0PGlkkg sTfPPD5nlme/H2W2dlyQqR3edVGFS29nLk3jHeeFL0tKTjMCIzEXQ4AasvHZfnjVxygK UCYJDzs7ppk+Xdkr6ct+TieArEpSPlIUoPGY5AtYkGpO+IukTB7NS8yUxopFjB4rBZ4L kichaxb4K9dOsE7qLVtGaHNEmlm7dRY2XOQJgaDl8Pr8ItEoUHlkSTbIXl+9FrXl+wAc 1HWwoFQ2K3Dmfcyn1m/6yTrJMNpGsSLyr5g5MMG10X0bTzCkOOiejNCHl2JIBcfrdCAZ kPxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787579731; x=1788184531; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=CTafZFi/HQ0yZlxsyK+vRPH1tJjqwxxSL7Z2p9md19o=; b=MoRyocJNU9g4JrW6MSlag/9jwPFKSETDEGzU1DiZczzwGGRECtn9z4o+jJb5On0AoM 08UeUg6elaqq2hqlucBEmoU3mUoKJAHNbVtsJf4Orjbx7GWFlphFGfxgw2BPIX0GwXGT OBcCeSlLJpAZSssgdIDjK1IGgd2T25LkmGU1NoHvJpANUnhakDLD1jACwpwVLRwD/J+F V7KqMg1lA5HAc83q3dK2qTLMDgOU8WDr0DZGNuJb07h41w4wrnVCuRTliX4V5MuIoKOS B+4u/J82e2tF67egAOnxppeTLNGfrA2dFcbUW5kz6X06mwEe/kxUfb/8PS6L2BSEcOnS +dhQ== X-Forwarded-Encrypted: i=1; AHgh+Rqe2rBYZ5tVhuMhFGxjt4fI7thPfxV/FM3e82ggSGAXYHsTjBhRxUH6IVfkCLZUuFug7E2znIp63MroijI=@vger.kernel.org X-Gm-Message-State: AFuF++mQ1h44TeCCq0Tffw9n0VCawiZu3fXiitKhHFybzf3phOXJeYzL IFVXQpAZiahgNxmpTLiQnGLAdkpzrfo5x+n4TDzFBPY9RUt3OVmmY1Ef0fugcHnS1PUsIjJ88zB odVnA77Q= X-Gm-Gg: AR+sD11j+32Gk7g9lgbOGAANVOzJ1WddSGk3jJeiFz3LVSTh2ov/BWB2Fdal/75ZqYQ bGoBejtKZnnYrbTeUF1MJ6ksohiq7pPpRdUg399SUrAaZikI3EIe42BfTVw+HKxR+TCSX+5JVhY dfC52mAputxvQIvdTFKmphGe9jLp1CVn60TsiS7bgx1wy8scUG3MCM4sYeA7QBDTB7Z2eO6T6W7 2EWP8rNkW6o54cBuw+VlZ9n/7FwA+vX/e1h76BGpkuOVpMGxg+8W4Rb4xMzB/ddzp73qg3Rh69+ GfknL+ottZ6cQzCFyfPo5efVRtxrGrFtBu+KwZxez7Frr6qzshh7uzADSADLsTqtmn3DkjS8shk JX8YN3qMbhrKB1cnfr+s7hYwpyJEJw0r2Hr5oi4KnToFXQ0llTCi9qHSOniME73m2/68+UMZqsX BROBk6M5fw4GEsacmUM/++ZLmjAoQMEabW6mV9lCrsAIdE9tIxGZCUNSMPRIJMviCHc2PcKubra Q== X-Received: by 2002:a05:6402:a5c3:20b0:6a4:e8e:9e26 with SMTP id 4fb4d7f45d1cf-6a42f1e08cdmr21176932a12.10.1787579731218; Mon, 24 Aug 2026 06:55:31 -0700 (PDT) Received: from localhost (109-81-81-112.rct.o2.cz. [109.81.81.112]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a59e199ad5sm8980194a12.18.2026.08.24.06.55.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 06:55:28 -0700 (PDT) Date: Mon, 24 Aug 2026 15:55:25 +0200 From: Michal Hocko To: Kumar Kartikeya Dwivedi Cc: Jiayuan Chen , bpf@vger.kernel.org, Emil Tsalapatis , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Eduard Zingerman , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Ihor Solodrai , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH bpf-next v4 1/4] bpf: Add a sleepable page allocator for map memory Message-ID: References: <20260821050250.35112-1-jiayuan.chen@linux.dev> <20260821050631.39784-1-jiayuan.chen@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=us-ascii Content-Disposition: inline In-Reply-To: On Mon 24-08-26 15:11:57, Kumar Kartikeya Dwivedi wrote: > On Mon Aug 24, 2026 at 3:01 PM CEST, Michal Hocko wrote: > > On Mon 24-08-26 20:44:18, Jiayuan Chen wrote: > >> > >> On 8/24/26 8:26 PM, Michal Hocko wrote: > >> > On Fri 21-08-26 13:06:12, Jiayuan Chen wrote: > >> > > bpf_map_alloc_pages() picks the allocator via can_alloc_pages(), a > >> > > conservative guess for BPF program context that is always false under > >> > > PREEMPT_RT. So even a caller that really is sleepable gets the > >> > > non-blocking allocator, which never reclaims and never engages the OOM > >> > > machinery. > >> > I thought one of the main motivations was reentrancy. As you cannot > >> > really assume the context bpf_map_alloc_pages is called from there is an > >> > extra care needed so that this doesn't re-enter the allocator from bpf > >> > program called from allocator path and deadlock. > >> > >> > >> Agreed, bpf_map_alloc_pages() is designed to be safe to run in any context. > >> > >> The commit message should be precise. > > > > How do you achive any level of safety for the _sleepable version? Vast > > majority of the kernel is sleepable but that doesn't mean this is safe > > from the mm reentrancy POV. > > I think it will only be invoked directly in the arena map fault handler, which > runs in task context. If an interrupt occurs and tries to allocate pages, > can_alloc_pages() will return false and it should pick the _nolock() variant > which is safe against reentrancy. So you rely on callers to know what they are doing. If that is the case and generally acceptable by the BPF community (no real saying from me in that matter) then make sure all that is properly documented. Because sleepable context is not merely enough. -- Michal Hocko SUSE Labs