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 70AD1C83F2C for ; Thu, 29 Aug 2024 14:27:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7A8E6B0085; Thu, 29 Aug 2024 10:27:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A02026B0088; Thu, 29 Aug 2024 10:27:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87BB56B0089; Thu, 29 Aug 2024 10:27:18 -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 678776B0085 for ; Thu, 29 Aug 2024 10:27:18 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0B05B160EE3 for ; Thu, 29 Aug 2024 14:27:18 +0000 (UTC) X-FDA: 82505510556.08.6459F77 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf22.hostedemail.com (Postfix) with ESMTP id E322DC0020 for ; Thu, 29 Aug 2024 14:27:15 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="KhzZ/G/R"; spf=pass (imf22.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724941591; a=rsa-sha256; cv=none; b=cH6syYyBiWh/A41zhUwam8bvxvhiyMOg77AKiET041jHpcOq9/pADz6LXFlGDhL+ipsWDw AJX1JJxGXuz5k82GN6bo76xATKtj8PXGIV/+Q29klcpYKrDN4P0naGbJO6sFDzTCATVT3L e0bKk6DueKRJxT7u5FlnuFVNgxd3owk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="KhzZ/G/R"; spf=pass (imf22.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724941591; 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=n2OOh+VCVK5/2MQz7ooKTOwltB8S/8ZEKBIDSHGLnlw=; b=cKjuUlurBEkPKCD1CavZ/ATno4PRN+eJY1cF5nRppIGHMTCmH01ACbxg8YUkvc1JqrNpUF 3H2nbWBc6FnqgCKr85zT8z0A8r6MMJiMlY3w7JUAjFQICi4T7jF+Gs0VwCN6ZyH6mryBGf Py5Jekf/Vuc7Pcd4fVLgc8LMUqA0iCg= Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-7cdf2ac6130so225121a12.2 for ; Thu, 29 Aug 2024 07:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1724941634; x=1725546434; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=n2OOh+VCVK5/2MQz7ooKTOwltB8S/8ZEKBIDSHGLnlw=; b=KhzZ/G/RdloxPtoSrleu/40SSXhdIReVeUgJwZiLDGEuixGAyvJjr62dik4byjGmBx IsPgk1yNSdrJ4hoTRAXC/X4nUUoL6FXmbfZnTuoXOH4EZ/Jhk2Z8wdoluib/CiaFiKUZ UTtfeP208Bz1vKd7TniPTyO2fy3uic6zwKcdjfn54Zk81qT6uIs8AbsK7QYnmpKKaoM8 mQIBv4/h/lLygtLiWdRIM1Rrw9ewSR/h9cEZbwuzNEMNF/RIeOJql5tJOHGs3gWR9l+Y RQCUUvfdP/aydfYDCAJP8n0gDF33jQBznJAEUvqwV+pfZlH9NZvM8yHRIqloV7l++NqM 3XzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724941634; x=1725546434; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=n2OOh+VCVK5/2MQz7ooKTOwltB8S/8ZEKBIDSHGLnlw=; b=gjsQS4c361EPFsIFvsQn9Ee/XwBMO9rAMZe4oDDxUhXYG4eq6Em+e/VK2FA7bw4KCX Mh3SNxdgeeFCgtIw+Xc8suSV2BdblfC3g478pTzT/xWERwmfnK6a8ik5bMtsKYGK3J/O a4MUygLaVnBtOuBtmFTOItsHEfdLa5t1woN2Njgr27twwBmfuWnFAx7UsW3nFNQqdlwd M/onTmYi9DkO/oRIKEHuNjAaIu4nevNl5GuE0kGTNgu0Eqbp+2Y1HrWVkVsHHhH2E6cd cqoeqSbVijtwDrdYCpkIQDGw+lzd4hJsynSRcfjUyRZ/al2w31iyxJvUWCyqvd8qF/MA K87w== X-Forwarded-Encrypted: i=1; AJvYcCUB0Fm+Gh4pMB2g/vjNgwBLqk1mnJGxQ6FLJEZTcyHfkx65ZymeD2VbgRbpviFWd3kUejC0BhNz/Q==@kvack.org X-Gm-Message-State: AOJu0Yy4ph04pw1KXAs3DsQ1t8QUkNJW3Nd7M+FO4senYcppa1cR5riu IGjaSA2JvoZU/vAqlPAWItNp4lW+rMNbtJ+lyWNMToR2ykmAGeQX1jXGJAtM6Ko= X-Google-Smtp-Source: AGHT+IHoOtZbO6aG3P1JZ9jG7nfRTKU3cDhAQsdkX112QyeI5JUZTX3EuDxdBLxMn0khFhYGynskaQ== X-Received: by 2002:a05:6a20:e196:b0:1c4:c1cd:a29d with SMTP id adf61e73a8af0-1cce101c8fdmr2841575637.28.1724941634275; Thu, 29 Aug 2024 07:27:14 -0700 (PDT) Received: from dread.disaster.area (pa49-179-0-65.pa.nsw.optusnet.com.au. [49.179.0.65]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7d22e9d4df4sm1270220a12.82.2024.08.29.07.27.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 07:27:13 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1sjg7D-00H16b-0t; Fri, 30 Aug 2024 00:27:11 +1000 Date: Fri, 30 Aug 2024 00:27:11 +1000 From: Dave Chinner To: Kent Overstreet Cc: 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: 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: 4b3q7yrpu19t43port687q69m7uwdgen X-Rspamd-Queue-Id: E322DC0020 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724941635-270009 X-HE-Meta: U2FsdGVkX199BKAVJPKB1oDJnYYSqAUqreGijhKw0FbLrL1LmcdJ8d5RjwvPF+DMv1GkvFCHI5plcadmQFIVvX7m2C13kSP+vMTFobrrGu3StTp2DKYpOot8LQPKuOvjSGroWRQXchdzUC/3LaQoy72EmUjh37RTfM0gY5ju1KbHadMwKAYHsRZk7Gw9GAig8yAjnrJWmHecS85AVssnhsvO2dO+XCIbZmr3hu9l2HdkXhwxbPMprCpPxYGxC280nmawLBL2kiP0KdRa29Z2N9GbzE2TcZCIai2L/G7Np11t+gA1FytKYjp/+d3P2Nyw3vYQrQJGxstvJG6m0yukJiK+H1lRmMiK7o7z1v4sR61/X90lFnvQ9Lmv10ayq/aWbqUV7VR9EHs7YyIgsvRMbTijFTMVTrqBWRndwZPPtfFEgxMkY+SqSEj/n6TPf/RqdPmMPSLOzvaolxSxM49XKI2YTGBjDuOHL/o/dMKn5Mqu8ZruDR/ecXiMSi0HC0DlGdPEazHossEXOKDXQYcnRDyLy9j/8cnqWLZxRnT1PhnO7t55Qrej75IXui0W15RPpIr9h6GS82ILMVUQSKLVFOiq96mxa+ZY0+zp/ojf8wYOFRTmYnyBEiCblxl9e8cZdvQvHR41owC3oKgw7SPUGfiH3rTjTMDL3hQo7KnCM6E5jFw7QC2qEqzoWp6msOy9JA7w1670QxSIt/53aL9yZIAgMPPSPX7eKR9qJcP73akakcduGdj6XX38d+kP4WbV7rVEWrNWTtKNzjmUwEhclxZHG5fJkqrmj2+xjnND5kPtoKLy1srew9QDprsK/KCHJT9imdHSfzm4chQXETfaNsKa33hFb/wIjw9iWgZiozybzHmku3s0bXl81aIeUQ013Q8rWo8BxQnwoGf687pwgnPx2OFv0WNnuWSQUfzCfEzvB5BJFUTysqX7azHuUWDAUVb9gUnsZP2Grt7sefN 4JgQDTvN 9Cw58cldmbYE+6Fv6auaypbhLC8511dQORr8HxC7dRtmZiGac1f8lk+S7chaF/egjg9aVvS6v74lhSwL1sjJX0p8z5BI8fcJRMk4SKGLgzDHsJieZHi4L5J/euyvjueQvJFeTk8tngfaD67IQDB0R8OfMdar+6bRTBOO6KoTK796D2mGaAUAzL9vRuHXlX0nS8+5vWVKuxmHv2VjJRb7HzgA6ByUUjuJTeR5H+isfuqG3OlfNvbgElX8gtoTAX4VUpGYs/zCkKAJkAEdT8rV1layA6JOQlW5xt8UQPlMnAHLLCZG74bnr77V/GhQEyhBw2xvS2IPbxRfiGTCKu26ee4s78At/a1+RVZapY1M0JqhAZgi4AnaBOh6zdj3QQIGbgYa180qXOVnRZTetI3sJ5boPTqanJx2uw5/lI7DH4z3sS79idZOXQ+lPSyK+OBIKescQHy8OnD/tVbE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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 07:55:08AM -0400, Kent Overstreet wrote: > Ergo, if you're not absolutely sure that a GFP_NOFAIL use is safe > according to call path and allocation size, you still need to be > checking for failure - in the same way that you shouldn't be using > BUG_ON() if you cannot prove that the condition won't occur in real wold > usage. 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. IOWs, __GFP_NOFAIL semantics have been production tested for a couple of decades on Linux via XFS, and nobody here can argue that XFS is unreliable or crashes in low memory scenarios. __GFP_NOFAIL as it is used by XFS is reliable and lives up to the "will not fail" guarantee that it is supposed to have. Fundamentally, __GFP_NOFAIL came about to replace the callers doing do { p = kmalloc(size); while (!p); so that they blocked until memory allocation succeeded. The call sites do not check for failure, because -failure never occurs-. The MM devs want to have visibility of these allocations - they may not like them, but having __GFP_NOFAIL means it's trivial to audit all the allocations that use these semantics. IOWs, __GFP_NOFAIL was created with an explicit guarantee that it -will not fail- for normal allocation contexts so it could replace all the open-coded will-not-fail allocation loops.. Given this guarantee, we recently removed these historic allocation wrapper loops from XFS, and replaced them with __GFP_NOFAIL at the allocation call sites. There's nearly a hundred memory allocation locations in XFS that are tagged with __GFP_NOFAIL. If we're now going to have the "will not fail" guarantee taken away from __GFP_NOFAIL, then we cannot use __GFP_NOFAIL in XFS. Nor can it be used anywhere else that a "will not fail" guarantee it required. 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. This is not a step forwards for anyone. -Dave. -- Dave Chinner david@fromorbit.com