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 3CC2AC4345F for ; Thu, 2 May 2024 17:05:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 758E96B007B; Thu, 2 May 2024 13:05:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 709516B0085; Thu, 2 May 2024 13:05:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F7906B0088; Thu, 2 May 2024 13:05:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 404946B007B for ; Thu, 2 May 2024 13:05:29 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A21C2160A1B for ; Thu, 2 May 2024 17:05:28 +0000 (UTC) X-FDA: 82074081936.22.229412F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id C05C840056 for ; Thu, 2 May 2024 17:05:20 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=WFDpw0wG; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714669520; 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=HGInVdZLJ8MTTPYJoCeG6l3pxlaxOYC2DEq5YeHKM9U=; b=e0V6QbEDN8MDKRREikBEoYtZAQHL7z2/thnuELYx+02oat+M3S2EBw9U9iedi3QeJo+4v+ Qaeux/ur6c3YUR853rMYGWo3o1m9ZTLK3Oq9wfVYKEl1SGIwZM+SoIcVr7gNnJZKjRN9NJ UHzYMu6xGIfAFJRWdwHSwzirLHROGcE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=WFDpw0wG; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714669520; a=rsa-sha256; cv=none; b=oVJOniZ5rbysYiiySZEiyAtS452wMISaJVGovHOa4KKK6P4t2nnNxzvV11BO7XYgO3s1Br pAf+/NcWsQRStOel3FozhmYTqDcDeeMd8kKc4fXaBmRdxIXUSJ26iK1adRAhu2Ppv1jvGG 8yGWp2tDZb54JILJfO5+ALJinZ3bHTc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 90A8D60B32; Thu, 2 May 2024 17:05:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31E1EC113CC; Thu, 2 May 2024 17:05:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1714669517; bh=inLpcop0Lb7aOfay9b8xok/bn6UOBqZfABOPjLwtFYc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WFDpw0wGzwR2VzyTxf8IouXr1iaLkycTisV2RNEWinWNffyfpEm0tfTDM+L6LV6k0 g/x+WPa+/9xDp6HjAWnw5oRRk9+8VFGI0X7t43TrfnzTgK8CxdXOa2XLb6Z608kMrf bgl3caiTv22Pk4IRcpnkJh9HQtTxh6mZKUPQR2MA= Date: Thu, 2 May 2024 10:05:14 -0700 From: Andrew Morton To: Dave Chinner Cc: linux-mm@kvack.org, linux-xfs@vger.kernel.org, hch@lst.de, osalvador@suse.de, elver@google.com, vbabka@suse.cz, andreyknvl@gmail.com Subject: Re: [PATCH 0/3] mm: fix nested allocation context filtering Message-Id: <20240502100514.cce09f1fab6914a56491debf@linux-foundation.org> In-Reply-To: <20240430054604.4169568-1-david@fromorbit.com> References: <20240430054604.4169568-1-david@fromorbit.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: C05C840056 X-Rspamd-Server: rspam06 X-Stat-Signature: bsfuoe9g9c1w8wi7j5jjgq3mz4kgc6et X-HE-Tag: 1714669520-87870 X-HE-Meta: U2FsdGVkX1+0AJnlh0gW1CA07up4P0zTr0NzbRdN0l+Gaus2cGtwFWd3xD49FkNtWMv+8+wWiMPGJ6KPWKQ+M0EjLLX2pFriPxhDNT2kw0onHCeNl5aSvQtxI6CllQqqM41rd6o3qW0LQ9An2R54kv5pic8JKSl0/Lrh7JMqjkpqUHUtQfJFCNPUeik48dFjBKg0Odl+zkPBJ4rz4QX+NRgQOzhWhXGzYjdymM2Fz+qcmU0jujJxAZAQ471uYiBO4oRzO48sDEaHmU4uuHGpL2n8ELZ/xlEQx/qya9rX7/EkWvac80CcI080gG2XMUvhhgVWiqMHJsvK5Txf959pBLQO4EUyYWqBU9tM07Z+Zb0Obj80tjbJ802KyoArrSzrjSfOnFpbWU5DgPFpzyycUnfrzJsZUW7bSQL1Cn6V2rNtZxlXkKKmNNeh+ZfThoyJOSH5/hMR2LDk7/Qz5FPXRygwrYA/mPvSuPKhbUGLvZEstsCkVjfV/0keJciyso90tLX70WLmFepg7mgYhuN3hh0GYNy0v+1slnRjRNwMDiANzveqjDU6kRQ/vt1K7ANxZQ1LUZVJoec0c4Y/POfX3GEjDTb08x+p2anfUArQBX30tz7o8sN2YBLrrgVpQNDV1yGJGLexoUJ2MjHATmT0a4egRr46TrhvvwwQ4zvWssaagAoFRzFTmtFV7uC+T+pBDp+vgx9XGpcoHQQ6sPAvwZTl1fpujv8ooENXQPYzq7gR5knIKmM2O1v+JL1jRS0V2pFiHD43izXNIgzyVg1vAoTs9Zfzupj0EzffxFNEcpRKL2q/RVi5eML9cGnHGRD775HGOWGKo66g3lGO+SifrwS7WvIsQpQykqeTClYEzsBUmiEqJ5Hjhq7xs8gj7/lZfaFAIHcUXWIPmsNsIr7E131h3AJ452MHxfPyH2X1gi2SDPCLqKks62f0NSLWlCBXNrPz0bUEGhBFl/3GDyc UW725XMW LIO27yjg/0ZMmmTvA9L4dN+RYT2w7fbYD0UkY+a6pZaeg+UxAlIrjrYqwwrD8QMqbi9T0SYhqccn9L3odbRSzZ/CIZ1OHSK60JZfJxpQ4RhKhK0aNypsCy2b5qyKE959Vn+1S4Hmlvfcxk5GS/a3OJ4gIRjoSpJ9YSWL8d/Z6cbYvdLc/ObYhXVa9V0HAYd+Is/S8vZc9805ftKSXXjMibwHa9ENnuFIR59/dBy91SQ5bhe9BK9z1G9ijSyop6/w45t4lFCy5lPYpKi5y88nLIcRsv3QPcf/27FOSsUz59msG3WG5XYWrq/ZutNACUC4FmEE3f8yVI3NeGvDDxh03YdqkzYS2PTICpsQI8MuQkR0ZWPrD36a2JRiUig== 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, 30 Apr 2024 15:28:22 +1000 Dave Chinner wrote: > This patchset is the followup to the comment I made earlier today: > > https://lore.kernel.org/linux-xfs/ZjAyIWUzDipofHFJ@dread.disaster.area/ > > Tl;dr: Memory allocations that are done inside the public memory > allocation API need to obey the reclaim recursion constraints placed > on the allocation by the original caller, including the "don't track > recursion for this allocation" case defined by __GFP_NOLOCKDEP. I resolved a number of conflicts here, mainly due to the addition of GFP_NOLOCKDEP in stackdepot and page-owner. https://lore.kernel.org/all/20240418141133.22950-1-ryabinin.a.a@gmail.com/T/#u https://lkml.kernel.org/r/20240429082828.1615986-1-hch@lst.de Please check the resulting code?