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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D17BC02183 for ; Tue, 14 Jan 2025 10:39:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAA896B0089; Tue, 14 Jan 2025 05:39:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B5AA66B008A; Tue, 14 Jan 2025 05:39:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A49C66B008C; Tue, 14 Jan 2025 05:39:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 878846B0089 for ; Tue, 14 Jan 2025 05:39:55 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 34C671A0911 for ; Tue, 14 Jan 2025 10:39:55 +0000 (UTC) X-FDA: 83005711950.30.1DC33B6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 62CD414000D for ; Tue, 14 Jan 2025 10:39:53 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=eE9vhp2Q; spf=none (imf23.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736851193; a=rsa-sha256; cv=none; b=pjT3LeDcz8S0vOGWUOpjVrRLzW1xHKGSc5MphIHBV+gKJDm2BJX+k+R+xTEFsDPWOQcSXJ 2HoVXbOHxT7grCoTMCepvwI54YiiBkx7gUZyGGpEkZ7x6Lr2gEiNV8wzO9Gq2lbJ0l7aLr ygpFdTSLKLF9DVlRP7PgyBg4G2lXV9E= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=eE9vhp2Q; spf=none (imf23.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736851193; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=r+w/cUtD5Y5h2ew6kp+OJi7qEEAey9zNgUW1NwUjHos=; b=Jlc9Wa3Y5uGQwFQfmN0yoeY/7AU1g69w7WlQTabE1AHuKv/F/xuzO10MvZpQyf/7ZqvULH Gu/Ziyrk4KqW0run5ePEvef/CyLZYzFGnnBSuxYNLWS+haDMesfU4mllpJr36ZnIea6XCX Ur3VFTut2tLG/C4moonXgvWEC6RSHSU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=r+w/cUtD5Y5h2ew6kp+OJi7qEEAey9zNgUW1NwUjHos=; b=eE9vhp2QryxWVJSCcHd1ild9eL lE9mq2O0gYqdLkmMud7HtgSg3qJ2TGwgSHaQerDPldc2noXM1B3jHvlv0drjKxfOW8KuPNRrfm8hG QGjE0unTtiG3GI7SLYAIuTuXTCk4cfUkq7EV3xWWOq3XLQmDQ2xsI/KkXtwCs4V1O79c2Jow4BeNL 6Lm6Nb6HFxAKdlFszhUkh+a3DBIONk2Hl3RGLfP+767K/4Ww/yIdWBr6+Ynm3OJ04HmCxNccOTYLc S2Uu74MQYDtA48NvI2BLHhG464RjSe6gaXgJzgRYueSVT4VLxRCIwUJPcQYbHJcpmses/V9QBDvZE go+YSCgQ==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tXeKo-0000000E2GD-35UI; Tue, 14 Jan 2025 10:39:46 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 4570A3004DE; Tue, 14 Jan 2025 11:39:46 +0100 (CET) Date: Tue, 14 Jan 2025 11:39:46 +0100 From: Peter Zijlstra To: Michal Hocko Cc: Alexei Starovoitov , bpf@vger.kernel.org, andrii@kernel.org, memxor@gmail.com, akpm@linux-foundation.org, vbabka@suse.cz, bigeasy@linutronix.de, rostedt@goodmis.org, houtao1@huawei.com, hannes@cmpxchg.org, shakeel.butt@linux.dev, willy@infradead.org, tglx@linutronix.de, jannh@google.com, tj@kernel.org, linux-mm@kvack.org, kernel-team@fb.com Subject: Re: [PATCH bpf-next v4 1/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation Message-ID: <20250114103946.GC8362@noisy.programming.kicks-ass.net> References: <20250114021922.92609-1-alexei.starovoitov@gmail.com> <20250114021922.92609-2-alexei.starovoitov@gmail.com> <20250114095355.GM5388@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 62CD414000D X-Stat-Signature: jrwfz7aa8ygjtioi3ip8eajgtatkjxsh X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736851193-230548 X-HE-Meta: U2FsdGVkX1+3mPIzW7nJn79c838RsYmbl2MFi0fbqJbomOJNu1erF1/Y2b9s41EMYM8Hhba/agOc6jjv5hdl+yhGtqDS/QaQnkvK4OGA9ZbRYm/qDw7u0AsE6IBg5twn1K2QkOyVeCn87LuAxtFwmYiATk/0FjWMsMBnkWPrL3fgnBwOxW+YqeH5VsQ29VAwE7OAx+ecHTAFPP4t5tEa/DSz5L8/S/NSCygMvHEtxvnwPYYOzRGGV2AyPWjIe6jOn0QJ//MHFbeZ9vdkdsPpVvODA/MCwJN6lIqaHxVFhx6pgC6r/AajeRZZaQodw/nMlrxXJ3XOoGpquLjHL/VJ/uwv0jzEsiaC1nKaPHwW84SYpzo+3AkKz5IINLWJMmR013vxDVH7n9NfSIW6xMQXHmHQnm0MSzIuuqaculoOI6/eHsTdj1MJzW0vkr2sZx594cJicZY8C2rfFulPwmo+WTu1vxsKH4YukZ60l6ixu5kAVpChz8Ug6oY8ZeZCHVyLTwcmWpE0BuXfwe4Y33TYWgIoSukaXwBTzjWpviLVlZbr16xsICxXngCx825biSqmnRpdOqGU7E9r2ctNJg4j23T/WcLHLz++vjZ/kTRnAKdCIslDjTGU+GzuWOL1dqYEYLZKA6U5zN7bRrlXUKIxhJeuBPNDVZ3Ma2zw7PGpWRY1Qlhg2+xi/GczRwBTFIllU0QyJl47NE7lMzHSpMoUwul3Zw3f2z8hjaOIkQGguADtS2TJipgL2kD0M6v6eFOhjgIVVYGEwNMFQvxIbMME95lEFqJdlMuPS6i74uTuV7llGGn/35d9CBRrSOwFiAjXc1pQDybaR35tCJTVzE1543m7haNmUbtq2kXSt7NhHwmn1jH00IPMnJdr5feb1uh9FYUF6s/94NemjaRfWto8t8VedEqyXIiGXg+piqr3ZKf0z1+S6MWk8AsDggDNSRca7c/a5AnvrfFu36202w1 54nrEhkF ID2OOBfv36//Cdzx4LUm3sQKAR2YrjVN6vodpQPhiNMcXCRhY9djT7o7Q3ZLwyWnEAUcvMBZQHyLlELGWxf4T18MIEroH6hHm7l4f7YRHj78ykaz8zZe9nIW3MBZyzgmMFylSGI2KaErfg3Fp7/oFFY1RIN+RwoCUOSRR/C9pK9LxRkkn+2wkC3cQwavxUxMAftL3SKmtM4QUl2kwJ8IlKyPAhstwust/1oPSeW84dfUtLMmF+tmZdhAuM4nHqcul6eFErfu2dsRxRwYwNChJ2NJ7oresQYMirRgxCFUZvfcMC4oOiaXTuQXuzhEShyunKv0a9klMvDnulQc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 14, 2025 at 11:19:41AM +0100, Michal Hocko wrote: > On Tue 14-01-25 10:53:55, Peter Zijlstra wrote: > > On Mon, Jan 13, 2025 at 06:19:17PM -0800, Alexei Starovoitov wrote: > > > From: Alexei Starovoitov > > > > > > Tracing BPF programs execute from tracepoints and kprobes where > > > running context is unknown, but they need to request additional > > > memory. > > > > > The prior workarounds were using pre-allocated memory and > > > BPF specific freelists to satisfy such allocation requests. > > > Instead, introduce gfpflags_allow_spinning() condition that signals > > > to the allocator that running context is unknown. > > > Then rely on percpu free list of pages to allocate a page. > > > The rmqueue_pcplist() should be able to pop the page from. > > > If it fails (due to IRQ re-entrancy or list being empty) then > > > try_alloc_pages() attempts to spin_trylock zone->lock > > > and refill percpu freelist as normal. > > > > > BPF program may execute with IRQs disabled and zone->lock is > > > sleeping in RT, so trylock is the only option. > > > > how is spin_trylock() from IRQ context not utterly broken in RT? > > + if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq())) > + return NULL; > > Deals with that, right? Changelog didn't really mention that, did it? -- it seems to imply quite the opposite :/ But maybe, I suppose any BPF program needs to expect failure due to this being trylock. I just worry some programs will malfunction due to never succeeding -- and RT getting blamed for this. Maybe I worry too much.