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 C554CCA0ED4 for ; Fri, 30 Aug 2024 03:39:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D54886B0085; Thu, 29 Aug 2024 23:39:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D041E6B0088; Thu, 29 Aug 2024 23:39:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCBC36B0089; Thu, 29 Aug 2024 23:39:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9D32F6B0085 for ; Thu, 29 Aug 2024 23:39:21 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 26285121464 for ; Fri, 30 Aug 2024 03:39:21 +0000 (UTC) X-FDA: 82507506522.22.8DF196D Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf12.hostedemail.com (Postfix) with ESMTP id 2C99040010 for ; Fri, 30 Aug 2024 03:39:18 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=mit.edu header.s=outgoing header.b=LzS0ZQ6o; spf=pass (imf12.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724989088; 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=iBN1OqKISlzImerjylAD7DIlwprKTEvfPiiXXj/dLaQ=; b=yz9w/H85rWa5ZiIrokg2YfTRyjF9H2xLzGa2Tz+v+Y8RDcAO2dG+7perFSSlgjhKAEcIG8 tzi92apl2waD/2vEtlt1KK0WCgJlpPdHvW71CqzBUwWzT9hNXMQuAgyRHDC28S3vGueCpc woj9qm37+3+f65MisUQNbphydX74jMY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=mit.edu header.s=outgoing header.b=LzS0ZQ6o; spf=pass (imf12.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724989088; a=rsa-sha256; cv=none; b=cjXMNwSwdmQuwWHcXrEkbYH0fhH6ZIIJQzOSSpT7UtCK+QSX3q3uu9mpJtb9WRH6lRwzSC ezSt0PqNiHggW+8UA096Pjx3B9msQG99Woafj2hFyrOi6h8HPnjteRHnq3TXbGGHCRZF4s foLPiuTZ6NjCL/V3ok3AucSiU8PMUcw= Received: from cwcc.thunk.org (pool-173-48-112-93.bstnma.fios.verizon.net [173.48.112.93]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 47U3d6d9028280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Aug 2024 23:39:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1724989148; bh=iBN1OqKISlzImerjylAD7DIlwprKTEvfPiiXXj/dLaQ=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=LzS0ZQ6obZmSSsyjaPriURvOuAoToFy5I4SVjGhUGdpCwKSIXBwt3LZQJrgW740CJ dGEwODnZCAyJ3lxGE+mn0WiD5tg+uRkVnfRYWXLozyKP18C+ODYuYythaN6+xaxz+t T4lyl4FHjRVGVUKlVOCnTyQPjV59vymE0AlJP6uON6/0OsI8iCWuYLNW3D70vqgOm7 qtW7ZUA6diTVtP2gWnXCOEelkxj4N3xzrXFPs4cg3FHB+1SeNUvAvAvF/rrOd4IdXU LohFASq22zl8qk2Yqh2KA26DCP9izryo8n3t5HLL4AxxV1HqAvwxPDx7qw8Ewvct1r e3YMRiCA0OFug== Received: by cwcc.thunk.org (Postfix, from userid 15806) id B367C15C02C1; Thu, 29 Aug 2024 23:39:05 -0400 (EDT) Date: Thu, 29 Aug 2024 23:39:05 -0400 From: "Theodore Ts'o" To: Dave Chinner Cc: Kent Overstreet , Michal Hocko , Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations Message-ID: <20240830033905.GC9627@mit.edu> References: <20240828140638.3204253-1-kent.overstreet@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 5hxj9uufd7sd63f5gp97gimz34xxy5oo X-Rspam-User: X-Rspamd-Queue-Id: 2C99040010 X-Rspamd-Server: rspam02 X-HE-Tag: 1724989158-734598 X-HE-Meta: U2FsdGVkX1/r0q84K5134PEHl82Kwh8E0q6jIMQq1u/MA6MDPQmnEj5aU5+AAi7Gc9F26213wSkDCDMlwBbgNzAYb5iJahyu/3uIk25kF4b7vVgVLY8nxLmbc7z3aGKrMKDPhi2lR5aVXvvvI1z3u3JWGdqGBbOpD4PDAQUvpzpl/nOPMXFIwoneMg9+TV2w9bGM4wBhv3k9Pf0m3cCJkLRtkNpOHJdyHimcFCnfhKg1ALIrcSOsgXoVmTw4ia1Tx00aLyQVDIP+U0ZrvIUs+5Sjs6d/V8jpeo5a1jDnvOTT6q8tqz/Jm1hdnS0wRzChATQV+HYblaxEAm3Z5nEjfZoI++pi0JxZ1VMBMPIqn8bjQLw6TQDNIyeSljyEHsFH/MzyQjKTKTQkG+ZijOdedebQL9SHJrNiKDJaAcDajNbUdVZFZgu6nFdIIuqCy/DiLZyv/2WlvkbKjqZD3IU6/OGjctwEX0wUrKNQBf+q65BnkrjfnUY9pMNHgSldDHVeSWVN/p572EBMYnAhfkaKGTAZlrrx2VAlHmI74DN+udJyit6utToZ8AwSVXQWFFQ3YgaOmjg2gvES0gldCVFHYamIx1omeqb8N76wYXkoiWMiXpaaJRe00inGd3kGAGgLe8hCNMTFrXcPbZEU3M2OUvhG48Otz1MO/xPtAB88gHZK1AFdwMa/B1CClVw3wuYSMyUzsvoPSBq8TwLA1L7wgHGOAZjETNDCkpYBKqkkwLoUaZ29ZnKZ2UfjGxrj6OzOpVvdqw8wbZS5WZMoM7btZXqIpqVNRHCvGwUX4mIqrVxvlvv+0Yb0D8u0iEBKDNpaqvoi+IzA/MVmIW/HHTrqZQcSdhGEqYj8J5YJsGYLanTKpfGSLSwbt7aj2KWY7YY3Qqs7ndIuwwFmglJPUrIhLg/7ecL+i42myXgYugFDDKOxecmBrxC6JXrfLvNp7cpTiglqtx1kRE8aAAE/xAP jY/xq+Eg wM1AP2V0/dpsHS50oAaN8/tl0Jh0jR2WokVgozQ3E8HUSVId7jcNIyQNMZW+41zn1pfR0i2FC7jUT56oOdJNxP76Zcg24+RL6A0P1QaQ8yZbFih1QY9h00nUXTvSo1ou4GFKIOtxeQq6wbHAyVfioPmmszQul6+FvswiieotW9tGKhgRZs6/DOQMtwPymaE7HuP3yyDTkUnQ56xxcWkhlf93xl+DR3caoczo701ZnNYGb96UAKcW9g/H81lyFG7p8AAZ0ADtVYPypa+A= 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 Fri, Aug 30, 2024 at 12:27:11AM +1000, Dave Chinner wrote: > > We've been using __GFP_NOFAIL semantics in XFS heavily for 30 years > now. This was the default Irix kernel allocator behaviour (it had a > forwards progress guarantee and would never fail allocation unless > told it could do so). We've been using the same "guaranteed not to > fail" semantics on Linux since the original port started 25 years > ago via open-coded loops. Ext3/ext4 doesn't have quite the history as XFS --- it's only been around for 23 years --- but we've also used __GFP_NOFAIL or its moral equivalent, e.g.: > do { > p = kmalloc(size); > while (!p); For the entire existence of ext3. > Put simply: __GFP_NOFAIL will be rendered completely useless if it > can fail due to external scoped memory allocation contexts. This > will force us to revert all __GFP_NOFAIL allocations back to > open-coded will-not-fail loops. The same will be true for ext4. And as Dave has said, the MM developers want to have visibility to when file systems have basically said, "if you can't allow us to allocate memory, our only alternative is to cause user data loss, crash the kernel, or loop forever; we will choose the latter". The MM developers tried to make __GFP_NOFAIL go away several years ago, and ext4 put the retry loop back, As a result, the compromise was that the MM developers restored __GFP_NOFAIL, and the file systems developers have done their best to reduce the use of __GFP_NOFAIL as much as possible. So if you try to break the GFP_NOFAIL promise, both xfs and ext4 will back to the retry loop. And the MM devs will be sad, and they will forcibly revert your change to *ther* code, even if that means breaking bcachefs. Becuase otherwise, you will be breaking ext4 and xfs, and so we will go back to using a retry loop, which will be worse for Linux users. Cheers, - Ted