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 98A4DC02180 for ; Wed, 15 Jan 2025 23:47:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FA8E6B007B; Wed, 15 Jan 2025 18:47:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AAAE6B0082; Wed, 15 Jan 2025 18:47:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDAE56B0085; Wed, 15 Jan 2025 18:47:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D16DB6B007B for ; Wed, 15 Jan 2025 18:47:20 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3F6DC120472 for ; Wed, 15 Jan 2025 23:47:20 +0000 (UTC) X-FDA: 83011325040.25.96430DD Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf28.hostedemail.com (Postfix) with ESMTP id C7149C0008 for ; Wed, 15 Jan 2025 23:47:16 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HvWross3; spf=pass (imf28.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736984838; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EHNq/pnk2CXWVu7asoZVq4jYoXWOdxzbfK/2GqNmkNs=; b=XgywTvfPE3fE9rl6BdcZ2uALJqU9ua465xop/ns11w7BbcoeL3v2RfV4Lu0XKFB6rEG4DU XR7zdLME6CoaloQJ0LQVX0f9eobXqnmzszs/DlvUADhmTV6X+LiCRuh0TJixp62uFlkvv+ 9RDvHrXNM+Ldt8rFMfodgLHw86O7jYU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HvWross3; spf=pass (imf28.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736984838; a=rsa-sha256; cv=none; b=jmRJ0oGMFyHyton4ZZTlVzW+86PHWk+JKL3VRYxFTdeJzGBTy1vHxB1Ky062t8Br3lGysS /Sr3NmsqC7HIMHF4sJ/CHHwSE+dbsUEXG4OFt5bYtli8t0wTFaJInMMwbODe//a/Rpnmgy 38XsSNMb4Xk9+fWdZb3GlqKffcejqeM= Date: Wed, 15 Jan 2025 15:47:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1736984831; 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=EHNq/pnk2CXWVu7asoZVq4jYoXWOdxzbfK/2GqNmkNs=; b=HvWross3YlmtIxpzMsqIJdkHSpFzZgil4N7xG1U766z9MAjyfNCgNG4aVd1wexsryr2nXT AjzDe/kYv0VSq0+Po04DXXHYLTnd0V/XKLz6flZ59TcTaz9bWlO1jVCjq1IjjPwfhFFfrz 0+NCu1vEypSu4dxZeUgAUzfzz6vVc7Y= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Alexei Starovoitov Cc: Vlastimil Babka , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , Michal Hocko , Matthew Wilcox , Thomas Gleixner , Jann Horn , Tejun Heo , linux-mm , Kernel Team Subject: Re: [PATCH bpf-next v5 1/7] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation Message-ID: References: <20250115021746.34691-1-alexei.starovoitov@gmail.com> <20250115021746.34691-2-alexei.starovoitov@gmail.com> <9fb94763-69b2-45bd-bc54-aef82037a68c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: C7149C0008 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 7u7pju58h3uqga4nawmsmymjeughuuzs X-HE-Tag: 1736984836-261727 X-HE-Meta: U2FsdGVkX1843WkZZZ7dmLASIGOETDz+OyGhl2/lxPU0Mp3sHwwKILL9Cn2yXfQYlH9mMJxf9H5/rh/eA1Yg8TnEboebPmvQwRsRzlBgPVuMM+jPG7qV34AH6y9YfNQCZWCoaDyjhTvco9Smb1gqPyBBFUfM/nXMDikjAhVyTQy3uuHTy0tN9Hsj+nd4yFcfsFwdYZqaWurbyf0kk43izP/TKkmO5ia279kw3Qij9wQtSJQIt1tg7IO6fIkDOBIvCxvovoYay1cPGs+hgFEk3WHvcsI8wTZ1LTXYaigfa846Roi0nzZxfbetUj8RYzLskbO1C3mGz5Ifsfm3C1XkNED3TsKeq34QscVcv62vtPGyfIuo2JTIqQ11Dd6T1IZAr6grM5i3iPDX5vXjJ6G8mHrSxPQYDg/278d3gdjYt6knL7q402xYVFaNDNuKmqolS/tL/yCJJ8VkGEW+Rbg0/jfw8t+hxPk7memU1hh+EdU+XPk3fI0+aOnZnA5TwZyn3unDjdGCtKg09c1fbMnU/fzORJillKlJKOk6u876LLI6Qj3VPzggh9H0dXqf83czvpElmBaUrYP/DujniwgayJXLG72WPqkMF79rYeC05emJQHb/JcIpaD0lwc7dRJLBmPd7HQho8A7R3dA3tMaJijzgi07MUw4pCgPONY3chu08+hJ7Nc51jrhCYVnoAy1eb936zkESO7g1EBdPrTBdPoFCiyWdrB08mLHhKpI0HuepR5LHkft7eXQPDX4JqcDRRDgjlqe4SoYb2UdgovudBGk/kR2/xgjzyZmaT/pE55EfCDw/iiRtxC5YE+M6NHwg0nRogKCzdJsyEAN4SesSW0aVaqwP/8ibntB/FT7WjoCgfmY8/lhBreNMZTR96Rv9XZ9eLrp6d1thRlufdlumZB9KGHGH3NGdEhcrpkSXUxwENBNyjkwj75hgeMC20Rb6UE+jLcMP7Hz3nh8tasl LCu1LEYR kkYckYC9mhMhVB1HG8TVJtgEa45g8yWWnNqYv9eFUHPuQY2DHVnVEnEzW0hJQ73ANuYDQr7awcXhKUFtq0ZQsrjGEH/xHD8vajIWDgo9vESe0/n7XUZqhhtX0e3SMnlrB9eiK6xHOkhPCEZ6YqleBxeAYxnSJ/0LHJOEnRSLd4NXhFGKqUjqMjmsPJQd1qn8kSBbSOl23Xd2ERP/5LLIbt2jTaWs8nyhSsX9LEiAUXXu3o4BmtNzafmmiFvVF5WWrRB1NI6Suq/FMxHZZKRXJgfbePBdmzw+Lne2C3uOHUTmf+nJ6FRdW5UgNywd7Oa/drFs1KreIFfKLOoM= 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 Wed, Jan 15, 2025 at 03:00:08PM -0800, Alexei Starovoitov wrote: > On Wed, Jan 15, 2025 at 3:19 AM Vlastimil Babka wrote: > > > > Sorry missed your response here. > > What about set_page_owner() from post_alloc_hook() and it's stackdepot > > saving. I guess not an issue until try_alloc_pages() gets used later, so > > just a mental note that it has to be resolved before. Or is it actually safe? > > set_page_owner() should be fine. > save_stack() has in_page_owner recursion protection mechanism. > > stack_depot_save_flags() may be problematic if there is another > path to it. > I guess I can do: > > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > index 245d5b416699..61772bc4b811 100644 > --- a/lib/stackdepot.c > +++ b/lib/stackdepot.c > @@ -630,7 +630,7 @@ depot_stack_handle_t > stack_depot_save_flags(unsigned long *entries, > prealloc = page_address(page); > } There is alloc_pages(gfp_nested_mask(alloc_flags)...) just couple of lines above. How about setting can_alloc false along with the below change for this case? Or we can set ALLOC_TRYLOCK in core alloc_pages() for !gfpflags_allow_spinning(). > > - if (in_nmi()) { > + if (in_nmi() || !gfpflags_allow_spinning(alloc_flags)) { > /* We can never allocate in NMI context. */ > WARN_ON_ONCE(can_alloc); > /* Best effort; bail if we fail to take the lock. */ > if (!raw_spin_trylock_irqsave(&pool_lock, flags)) > goto exit; > > as part of this patch, > but not convinced whether it's necessary. > stack_depot* is effectively noinstr. > kprobe-bpf cannot be placed in there and afaict > it doesn't call any tracepoints. > So in_nmi() is the only way to reenter and that's already covered. Are the locks in stack_depot* only the issue for bpf programs triggered inside stack_depot*?