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 ACD93C5321D for ; Mon, 26 Aug 2024 19:55:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FE2F6B0085; Mon, 26 Aug 2024 15:55:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A9C96B0088; Mon, 26 Aug 2024 15:55:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 598B96B008A; Mon, 26 Aug 2024 15:55:09 -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 37F326B0088 for ; Mon, 26 Aug 2024 15:55:09 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E833DA9E19 for ; Mon, 26 Aug 2024 19:55:08 +0000 (UTC) X-FDA: 82495450296.28.5307C3F Received: from out-175.mta0.migadu.com (out-175.mta0.migadu.com [91.218.175.175]) by imf08.hostedemail.com (Postfix) with ESMTP id 239E0160008 for ; Mon, 26 Aug 2024 19:55:02 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="pdkoi/S/"; spf=pass (imf08.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724702064; a=rsa-sha256; cv=none; b=1UTREAOIJcKP4chogT3DpqcDiePvsTasTvqCxsies8kcyS5dBPASEGCX/OfCWAlKMm67tt U+LHtQ6SwBlO/fYL0y0q5ix5GnmubH4/S0SABlQTxmKOm2EI6+HoPwzS4C1rgUPE8Rorw/ 5qjEJbxfP/GVk8HjsIHqDBenQqwPOU0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="pdkoi/S/"; spf=pass (imf08.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=kent.overstreet@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=1724702064; 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=/ruExyvd6gxPtiLXw8MJ5M67mJMswkxY6U+zhoDHwHI=; b=cw+hWPHTsPcDaFg5wjQmtHYhoDTi01tKuoSnhaObVie5xUnAQqNnJXUX0yFZ9lsszf0X/m 67a3nqBZ2p3LbUfv4TQhx+jEIFzV055gw9GdLKPpLOUu0VjnQCc3M910hmjjGJxp3Z1PvE Nk1YExoWmnhGRjwFJtiBByoRoQfluQk= Date: Mon, 26 Aug 2024 15:54:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724702101; 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: in-reply-to:in-reply-to:references:references; bh=/ruExyvd6gxPtiLXw8MJ5M67mJMswkxY6U+zhoDHwHI=; b=pdkoi/S/Dr0rAlm9V4YVflbW7gKVDBKd4If8UuxbhWUQR/EWStR1Rp582L6Vs7jgi1Z+7b RNayvFgXNk/M/EtErDYgpws+rHSVzvnKBmrxYYlXH+P7/agdeTqPGznkpzN5Z2upBuolTe z0X0oRQwESYT95iJ/a6tZQgWTSi2SZo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Matthew Wilcox Cc: Michal Hocko , Andrew Morton , Christoph Hellwig , Yafang Shao , 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 1/2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: <5m5qksxkvj4cvfzczqzleyortpe5selbrzkwlgbdc4ia5btg5d@mcaycdzfn6x3> References: <20240826085347.1152675-1-mhocko@kernel.org> <20240826085347.1152675-2-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: ioce87m681d1khcywifyrj3nnc6hxyp6 X-Rspamd-Queue-Id: 239E0160008 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724702102-299700 X-HE-Meta: U2FsdGVkX1+L87VOUI8GW8kDEZefI95Nn1RdndmSQyOinYWFcHzzftNwqngY9ccdJzC2p4Yc62DVlrzMe5yVYUuEwDPVi62NXwTbW71hoXoZc1xmvnrLjnneEvjizxFAopCiUZTBvYgqwfKHAQISnMKrj1CWK46hiBWntsBoYvIf4/qjZ8f44LpxqAjQmcJGfUISpgOtitKOz5TugESHTZrd6Pp0Lj7SRPKtJ+h6rLyA03SsjRfyYVcXJDTN0UmkP81kmNvW81OTmBmd1pOgiHV4lt+7FZ+ELlFKotgI3c68uWotzlehvD719JmBwgmIi3pfRXoHjRespg1XPXblquhVfa2nL2YgcZ62wBLmL1rgfyt7OP1QoFNfsikqKuWMui1PRDwWEV/UiUQ3Qw4+3X0+3Cxk+uEbJf4I2Yv8c5EKDd0JhaEUvvsIL3H/2mro3bc7+fdiVF1RmizsuShegqdRlHrS3A+DYSG7x1tUqfrMZUDWuwFvYqK3xsaov2D+enZx9c56VWzo7ayL/Z96HTimBE53EQ1Hc0rroRRFU0sony3IN/NvcnFkIpzxT8TlMHXkyEPNyiF/Ko+hZAv9lTGjCOdwk5gWnt5s9gWuo4Eu3wbFcAjm5Pqj8YzfexBx7u0Tzh+v+WzbhwvTCRzcUjSsZ9/bmc66L31dFGQlhxHgQMiMOaWLDmc2y+MdD0dn5j6zINIpOoxXfdaNX6AszmrMxQYxhHKUdfN5sXR0MVBq683nSJOF8TX9UxNOJvhZZ67CsLYCFX1owWM8XSUrGy8Bok5oR8zmMYUpWM/a9dj5WHfrdHCycylrgiow+lh/+b4VSM3ao02i56nw/4fQodhkRz3TesRhNPIc8MdJDGxgRiGPNpcQzGzHs0UtY9LKIg5f6z6lAah1NhtNGRrxko51z23c8cIe1BmDK4fF1OrtCOMz0yc/teA/gfK12rJtcgeJQc7tQf9G6CAGGsE qwypJk60 FcQ+p79yQ+CzB7I8gLziZM+O9EColivOcW1OVDS2NRibDMHUGcpbaeiV08WpOon0fC/aftjDFyHL+ZD78vLHd1LXRSz5hmi4GXZ05L5sW3ELntze7cwS8iuVCffkcyywHWh1SirxJ5hgYGWArZiBe/4Mfbzem2a1RElkEYMGD6c2JD4qYk9FrMmhiWJ+VGis9lum6Lu1eCmTtouI9MYb05++NAjYLE9DgnzEL7NAL6C25utqLBYvAESQkiQ== 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 08:47:03PM GMT, Matthew Wilcox wrote: > On Mon, Aug 26, 2024 at 03:42:59PM -0400, Kent Overstreet wrote: > > On Mon, Aug 26, 2024 at 08:41:42PM GMT, Matthew Wilcox wrote: > > > On Mon, Aug 26, 2024 at 03:39:47PM -0400, Kent Overstreet wrote: > > > > Given the amount of plumbing required here, it's clear that passing gfp > > > > flags is the less safe way of doing it, and this really does belong in > > > > the allocation context. > > > > > > > > Failure to pass gfp flags correctly (which we know is something that > > > > happens today, e.g. vmalloc -> pte allocation) means you're introducing > > > > a deadlock. > > > > > > The problem with vmalloc is that the page table allocation _doesn't_ > > > take a GFP parameter. > > > > yeah, I know. I posted patches to plumb it through, which were nacked by > > Linus. > > > > And we're trying to get away from passing gfp flags directly, are we > > not? I just don't buy the GFP_NOFAIL unsafety argument. > > The problem with the giant invasive change of "getting away from passing > GFP flags directly" is that you need to build consensus for what it > looks like and convince everyone that you have a solution that solves > all the problems, or at least doesn't make any of those problems worse. > You haven't done that, you've just committed code that the MM people hate > (indeed already rejected), and set back the idea. Err, what? I'm not the one who originated the idae of getting away from passing gfp flags directly. That's been the consensus for _awhile_; you've been talking about it, Linus talked about it re: vmalloc pte allocation. So this looks to me like the mm people just trying to avoid having to deal with that. GFP_NOFAIL conflicting with other memalloc/gfp flags is not a new issue (you really shouldn't be combining GFP_NOFAIL with GFP_NOFS or GFP_NOIO!), and it's something we have warnings for. But the issue of gfp flags not being passed correctly is not something we can check for at runtime with any reliability - which means this patchset look like a net negative to me.