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 84DC9C5321E for ; Mon, 26 Aug 2024 13:59:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 09F436B0083; Mon, 26 Aug 2024 09:59:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 04F4F6B0089; Mon, 26 Aug 2024 09:59:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA6FB6B008A; Mon, 26 Aug 2024 09:59:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CD62D6B0083 for ; Mon, 26 Aug 2024 09:59:40 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 55ADD1A112C for ; Mon, 26 Aug 2024 13:59:40 +0000 (UTC) X-FDA: 82494554520.01.AF28A6F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id E6191C0004 for ; Mon, 26 Aug 2024 13:59:37 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PhIk7oZX; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724680709; a=rsa-sha256; cv=none; b=MR2jusQ34GG8DcCzcTp3FKNEESgS+OhwBy/5SQzRlnrpu5OEO50rrnCLsG0iar8W52s+v7 iuCvCFzQ7F3ZfxdLbdRc+elGjVBhGQcsSaKKRjv/dp9S9SGP4pl9B8JDezcvHgDJpbaIwh WlCFiU2rYAvn/dc0YppswOxffmRw5pc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PhIk7oZX; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724680709; 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=d9ixmwiMI0t+BMY931VrpBckLQD4BASs08boObwsOs0=; b=1umNemGKY1BbXWl5jxpUtQsmGN47DoVlRqxyCxFNIQn/asE0c2pXeeuJyeZoHwTn+39ly4 hENvODa0Y5JDLX3JVNxRFYXAsCIUNWCcUD/thGmDvvIsm5Zv9LyvWi3RB2BAbEuhDAOdGq as42YrvHkRbcG/f/OvVODGHDq54r9/s= 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=d9ixmwiMI0t+BMY931VrpBckLQD4BASs08boObwsOs0=; b=PhIk7oZXa/Gkm39cnR6HKbAqgT CGgPgHcTlZl+DUS9UqdVVhPpauTPgAIuqtWaw0JHHCxL0FXfttu1cao91QOvhMt67LRmAp2NEkOx2 cxJh6nBHw1GlAcGiHLnhR0Hwd3yY4ILNspDZt0Db4Cs2BK2LnpJEoPMPnG5hgpUv4HWyudQsNtvAl rfW3hzI1sNJNXWmMA6mnx2bfeUGWrz1IXyyl7OnK9sV6a4P3/kgKIeW7VsmwKyyUROeKzzJu17e2m V6cJUt9lKMMgSEge6FqTwRlGm0Vcc2IV3xvfVgfte3cUSCKC3AX/IQmoy+XmM6zR8nSNCytePcQWC fITMZ/2A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1siaFl-0000000FSeG-26RN; Mon, 26 Aug 2024 13:59:29 +0000 Date: Mon, 26 Aug 2024 14:59:29 +0100 From: Matthew Wilcox To: Michal Hocko Cc: Andrew Morton , Christoph Hellwig , Yafang Shao , Kent Overstreet , jack@suse.cz, Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Michal Hocko Subject: Re: [PATCH 2/2] mm: drop PF_MEMALLOC_NORECLAIM Message-ID: References: <20240826085347.1152675-1-mhocko@kernel.org> <20240826085347.1152675-3-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240826085347.1152675-3-mhocko@kernel.org> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E6191C0004 X-Stat-Signature: zxawseyckexp9u5mfh97roitkzmb8cfm X-Rspam-User: X-HE-Tag: 1724680777-188945 X-HE-Meta: U2FsdGVkX18KNl6JughDJDfLmhele5h5iUJt6ihPNrucNuFU3qprqdY3pe1Fm1jnbrA+XJ/opeSFjQj6h29pX0n/rznAGg9OnjbyedFk4r6pOrSb9eQ+Fu0vBdLKz5p94LcjF0OqEnTV1f91vHAW0TZTngsSFtczl2z4TamPCKK/vjBqAtnKr5PQh+bO9q0Pc+JFigEmpfkLL3qkm6yGjui+4CAV6VF6PFuzlphuOoOLIxIqt4zAQ6SNis3qzsf9z95LvOMW2/WLkIr+WNt4iUPYlxTPwD4NKwstzb+NX/7PzfE4A2+BqjIZPjBoc33zFuWKJPnu/usIAiSPGc7lENAuHY5zRJ8s7AaaZt2+Nb5c9vrzgL0ctbc4JRzrx7x7cTgoKaFv7J0Pft+U92cn1tiWkC6izjni27YWgJXBreu7xxIRj+luGGv22vJgAmiDuL28UTYkjpCmshb8xYKIk0AfjjAKNiO/qAGpFVRbE04NdeMnf36EHawQ90X6zqIYRf5iKweiEYYDcg/w78TI80Nmr/P2+lCdODvAdPKBzdWIsdbSIxF7VDCezc6X+aDsBtoZAFI0BbkRqj1SsHk4mrY/37FuJZFbYVehfxGLrONmJicHfcbaO6gp+sq38qdmbu46U1uxeU5xut9qnzPJZQlI71DoPtSXP/2f3nItXe3rZbUbinOHMa7ByY29VrpvKg30Vx5otUlnwkBWl5AuMGRJo49GSX8RmiwEIPn9BW5QPUc7NlF5JBIyFqFaB0Vn2Tq0OmqEMCxRGcz4470xeZo56NddoDFD1mg0RFRiSY/yk9pbE31JHALOKEQuDaKzwAWfEJ+WktpmJhrVCw5Mv97VIaenc13n1qEruuI2nkNXOJBURrVvB1sgj8Sjnlm8wzICbsO2+eyQ9gJV+Nusp5LhNnvViGFbK2cD44jYtMHc0Sigbe6V332DJRylfjD5sS3IomNO7Upu3m4/HEl uXaXBQHx xV2d4kxxyn7lBhoOc3KNKHNC/Wcw8YlH5CSUNk7wrt6JbhBYb4+YB+ENf77DViOyPKf5PI3HRDPw0pyQEEOkxQi6vrH4+ugaXdvd9EobZ8gtpHUuoQy3rlTrbSqmD9glqbzhD+OkdDkJXAWzZjmXI9vf/9K1Kl1ZfUrGF8ZjhT87qDcc4z9O0qlZ8hmw3EOq0ObPfAq6dQ6Dh0jahEZEl+Bw5uAAyXZ69MzZdOmAdnBprIsBgzzey6Ad5nb3id6tioxMvwWU7AwRkbGakZNPVWOCcIhO8LmQbmjIiBdzfTTGlL4Cj0RBu+K/RD/+BkI0TloPZ1GqRhKKI3CgcS1NINloCNf7In2HR1rTNwFtfqFViD4PJRbwrSUqZ1i3NXaRDz8Zf 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 Mon, Aug 26, 2024 at 10:47:13AM +0200, Michal Hocko wrote: > From: Michal Hocko > > There is no existing user of the flag and the flag is dangerous because > a nested allocation context can use GFP_NOFAIL which could cause > unexpected failure. Such a code would be hard to maintain because it > could be deeper in the call chain. > > PF_MEMALLOC_NORECLAIM has been added even when it was pointed out [1] > that such a allocation contex is inherently unsafe if the context > doesn't fully control all allocations called from this context. Wouldn't a straight-up revert of eab0af905bfc be cleaner? Or is there a reason to keep PF_MEMALLOC_NOWARN?