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 B7505C83F1C for ; Thu, 29 Aug 2024 13:33:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4548A6B007B; Thu, 29 Aug 2024 09:33:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40AAE6B0083; Thu, 29 Aug 2024 09:33:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F2016B0085; Thu, 29 Aug 2024 09:33:02 -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 12B8C6B007B for ; Thu, 29 Aug 2024 09:33:02 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BF679A05C8 for ; Thu, 29 Aug 2024 13:33:01 +0000 (UTC) X-FDA: 82505373762.09.AAB5B0D Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) by imf12.hostedemail.com (Postfix) with ESMTP id CF55C40002 for ; Thu, 29 Aug 2024 13:32:59 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=T6TED+FM; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724938307; a=rsa-sha256; cv=none; b=J1ttoRqzm9z076XDmIupyWyxmsj8NqfFf27R8dqveZUyp656JkfeYkmdqp4CBqGY3h0qn2 qRRbKCcHlA6ZV5njoQkhdXSNZq/Og/gDiVe9mLVEHunzVEQMuobahdvECZumOn+1y/6E7+ mSLhrh5CLP22TnNtZUusG5k8/BryICA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=T6TED+FM; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724938307; 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=FMYh2t/Xz06IccaIYuj8PThdY4q4wdLBkOxrHA87gG0=; b=wUd2KT5+7AVwNSiXMXpG7hpGxwe2hGTUejHPiQ9ybnoUbtX/EbxEBbQjeQzrXUjEdusRxN iyoD9pG5pglxWqXOxZO5RQ7LepEfRASk6fUiJ1hPNVHIFZRQp8IgXNXsRafm78rr5rk9bV lOXjzmnoIW/duwFzGJBuPM5Wa6JVtqo= Date: Thu, 29 Aug 2024 09:32:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724938377; 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=FMYh2t/Xz06IccaIYuj8PThdY4q4wdLBkOxrHA87gG0=; b=T6TED+FMht0q0Dk5tidPaathkn2+ohL6nI1MGeFi5us1haLo+ggRUNhu0qAUGwtH9Hp5rB eblF+eWaDFMMxxJhCwe7KQxVGHZu9wXtip0wmFtBgOyjN5F06V9a+PM/SQlwjlcOeId2Ek UUUYcOya0qr4wKo+OFZ0keJMADwF7dg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Dave Chinner 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 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: References: <20240826085347.1152675-2-mhocko@kernel.org> <20240827061543.1235703-1-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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CF55C40002 X-Stat-Signature: adp1r8jxg5g7xfpnng4m5acbagb8gpmi X-Rspam-User: X-HE-Tag: 1724938379-507637 X-HE-Meta: U2FsdGVkX196nNHxANVsZAqXBJoRY5u5GEPz8OSsFD1wWKcuZ32oKnAwpxEc7HZ8MRy1WYae7S+1Tz7GRr18y9ABP3TToNYZiQ2p1jyTxSHnoEsRZ04RMsqIXvmZtjzjSvcr/UyyrCeDyrzQctfF9HINoCnh4x6ymO0029baSZcBzhaUoPDYEvwnd5s8+CmUOI5boh3wiFvZRrGkWUQwAMiKtan5Db5hXFyThW9zw6zKs/9awfVf/FqXfcUNm7lRg0AW7Eu++iEvLiU8x3rFjiLnEX7CHkZ0zdxQo9jgcEhveZH1LaA8NHJXrcZZWjGAk4aHtgqd2X5JAYXVcYOHx3tnlVt+ABzyOPLo58sEJdqH4noTndIS++1YCJUovtpz0LVuk7rh3URAfTSaeah0MyRi85Htr+khT8EFC1oyLLsaX67eZqYBODfuzlmWUo9MLj6+Brtg4UUEmxP+cogsByPiGfoXS05NCJO4O0UnOQWa15EH1G9lsr2VdF6kIVKY8pTnhKiYsFIGNzK8DJhjpRGxx+6eWhM0eIrGmIYNdHjJ5JHSvpvJICC7P4u3wflmpxn6nVdrHPrSezn9lvlQebm0p+UyMGQ5kVxH8Fboxf1PGZ5sUPqz6PupM+lU4DJ8nMt0i+xbidRlxcWIXzVd+6XhZbHh+EQV/TLeUjdT4z2kPVou9m851asgosoExQui1Anv4ZkIlVzya5ETNu1MvL4Y6rVkdVJAsX+XkZr3LsCkbaO9Z2Ms5CEKu+1N9xx1XlBaKxhb2H2lSbdBH/K28g6X1fR/nB5/GMsZuT0OIo+OLBWr3hmnP7G9n2hXEOq2PmStXOLCsBdUN6hWZpzqTbdhlCSNx9ZeTVd6BrXi8FdX1ES96xY65JglJMHg/bZolvlRZILjxsTa5M3hYd75VTfXtyNnROhHwpgX0e3gpqW+RKgcDVrlntY5vxJnqOOLMTZhWxjTVmz2Lrwg+Tp BpN+E22Q 1yGMEsh2PjGF4+ed0iu+FFGhB3ZLw3G35FVdevMi69lx6vw1swljXWs9uIaAYxljuh6uqk52g3J+9l40A2srE/pF5jUQB4Pq9lXuOKrPrzh4IU9p9UV6x2ZAHJTxdN7HKkhn3h0tE9DHDl0rVEBkjdsFzMf4h+7sMsy7tXJkJpjHPT5r6VcWcZKm7gR4lS+xL6A0nzyyjlNxbt3nW3y4OuShzW66B/boqZY5rfKUnyVdvbUQRCI2Gw6dt4gYwZ3lT3i0RkXbzWggqxJQiSRD2D3SAFz+qui6yhqInLefGNypD5IyzVJXPA1OVDJ7G/efbaUFd 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 Thu, Aug 29, 2024 at 11:12:18PM GMT, Dave Chinner wrote: > On Thu, Aug 29, 2024 at 06:02:32AM -0400, Kent Overstreet wrote: > > On Wed, Aug 28, 2024 at 02:09:57PM GMT, Dave Chinner wrote: > > > On Tue, Aug 27, 2024 at 08:15:43AM +0200, Michal Hocko wrote: > > > > From: Michal Hocko > > > > > > > > bch2_new_inode relies on PF_MEMALLOC_NORECLAIM to try to allocate a new > > > > inode to achieve GFP_NOWAIT semantic while holding locks. If this > > > > allocation fails it will drop locks and use GFP_NOFS allocation context. > > > > > > > > We would like to drop PF_MEMALLOC_NORECLAIM because it is really > > > > dangerous to use if the caller doesn't control the full call chain with > > > > this flag set. E.g. if any of the function down the chain needed > > > > GFP_NOFAIL request the PF_MEMALLOC_NORECLAIM would override this and > > > > cause unexpected failure. > > > > > > > > While this is not the case in this particular case using the scoped gfp > > > > semantic is not really needed bacause we can easily pus the allocation > > > > context down the chain without too much clutter. > > > > > > > > Acked-by: Christoph Hellwig > > > > Signed-off-by: Michal Hocko > > > > > > Looks good to me. > > > > > > Reviewed-by: Dave Chinner > > > > Reposting what I wrote in the other thread: > > I've read the thread. I've heard what you have had to say. Like > several other people, I think your position is just not practical or > reasonable. > > I don't care about the purity or the safety of the API - the > practical result of PF_MEMALLOC_NORECLAIM is that __GFP_NOFAIL > allocation can now fail and that will cause unexpected kernel > crashes. Keeping existing code and API semantics working correctly > (i.e. regression free) takes precedence over new functionality or > API features that people want to introduce. > > That's all there is to it. This is not a hill you need to die on. And more than that, this is coming from you saying "We didn't have to handle memory allocation failures in IRIX, why can't we be like IRIX? All those error paths are a pain to test, why can't we get rid of them?" Except that's bullshit; at the very least any dynamically sized allocation _definitely_ has to have an error path that's tested, and if there's questions about the context a code path might run in, that that's another reason. GFP_NOFAIL is the problem here, and if it's encouraging this brain damaged "why can't we just get rid of error paths?" thinking, then it should be removed. Error paths have to exist, and they have to be tested.