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 EF301C3DA4A for ; Mon, 19 Aug 2024 16:05:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8104A6B0088; Mon, 19 Aug 2024 12:05:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BFF56B008A; Mon, 19 Aug 2024 12:05:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6878B6B008C; Mon, 19 Aug 2024 12:05:36 -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 4B7F16B0088 for ; Mon, 19 Aug 2024 12:05:36 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 022BE1C3DF8 for ; Mon, 19 Aug 2024 16:05:35 +0000 (UTC) X-FDA: 82469470272.07.71CB693 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf29.hostedemail.com (Postfix) with ESMTP id 9C16412002E for ; Mon, 19 Aug 2024 16:05:28 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=AX7dthI1; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724083451; 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=0av1AdwzyMt+HVE6FQ9tUPI5Mm9RtXw6l9qSQ7ZGdPE=; b=sJIuO88MFzwFaoQkOtXCkxSQWYOAG7HzZmRl3EvGJ6DshVOJsY+guXGZn3LTcB0pDWb21o if//paJyV7gCqmPwMlzdFiat2YnSwMdM2KM00Y70DiChchlQLZfsbrwKUuN2dT8BdIXPVd G2yo3quJCDkxizV73IgUaY+WIN5i4SM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724083451; a=rsa-sha256; cv=none; b=3GtVpuho1eDSVu86JKeaRsZXYoW4Z0rmeQS8XMEOZhWv2b/LzNTQ3yGjwITPNaZEQbQvX3 Bxr+d9x8Oy8ERLrsSwa5dB/hGpeKLGkUf7XUTLAThTiXMgWVvP+jAHOOoMbBo1r9F77f/f klvMe0mhtUe1LJ5t/jsKRCMqineOfjE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=AX7dthI1; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2f0271b0ae9so56432321fa.1 for ; Mon, 19 Aug 2024 09:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1724083526; x=1724688326; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0av1AdwzyMt+HVE6FQ9tUPI5Mm9RtXw6l9qSQ7ZGdPE=; b=AX7dthI10foP8fwbbvsYeWyR5SIvYVYas45ypwqqv5yhi4m0aOO87A23Dsp59N4egZ YSIiXLgr4xFgRTicRT/aUX56CQNy7H4YqNwWy03x9vdnPkMw9tduNN0x+auh7jVPStg+ c0D5TZDvXKxSutBg/dpPOiRNuHt7WP5ZATU2E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724083526; x=1724688326; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0av1AdwzyMt+HVE6FQ9tUPI5Mm9RtXw6l9qSQ7ZGdPE=; b=r6k7yuCraTJJ0SZ0yhSV5BmDOvSi06/rJuSRpEivDXwaxCgPrta68L11XpQorwAqcy x74Vp1PsBVNf3gK1OkSHJs3zWjZwVB9HYh1418853yNWog0FDZSsRsNBNzxujzUt+3jP endbW0KtMViC6aGPB2qQa3Rm2djBnEgR4hm/E+mYSk7hX5mptE4dkEoHjw0ZRHNJlLYK zyJk/OjdMyYhAVy35IXOeuuB2UckeZdIaKkLJcjqzKNcafO2uEc4n5ucj+9VTaO8CEko w/qB4mJdoO/AdNDwqzccQyufuqZasM+vXmQ9+v1vcubZdUpnVyZNEcZOIW2t+tPhKkgL LpYQ== X-Forwarded-Encrypted: i=1; AJvYcCXPF1a+AKYReUrQ9eIkUaO2qEJ1TDwIM1tMnSDpfklebdfn4NQLCulxknpGhg71NtlM0dvoT5yE5Rqmtq00CZIXLmA= X-Gm-Message-State: AOJu0Yx/liN6PyzfFxeWordnl2kX8o2Ag+4dEEL1D1XUIUNrvEtrwqK7 46bxPVAHaS221iWUL1uAxNtuhS+XGkZeae3Texbadjp5JZua/cSEPggKRnFxQB65w472GwBNiT3 PzqLKtg== X-Google-Smtp-Source: AGHT+IEBWz4XqTC9Uhyrsa3eRX6GU7hlIxbUE5y8+so9dCSQs4KBw4OjU4e2s3XXMcXsHZOA/ZwFnQ== X-Received: by 2002:a2e:b353:0:b0:2ec:3d74:88ca with SMTP id 38308e7fff4ca-2f3be5988bemr63732531fa.25.1724083525722; Mon, 19 Aug 2024 09:05:25 -0700 (PDT) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com. [209.85.208.52]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5bebc081a24sm5636953a12.95.2024.08.19.09.05.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Aug 2024 09:05:23 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5bede548f7cso2539554a12.2 for ; Mon, 19 Aug 2024 09:05:23 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWME6InzsnlooxRF6vKmkyQ5cGY8To0skLU9d0JmWVr0ntCf91l3XjCD1oI5Gm8V6VLIRyTKH/kfvK9O/1nAK49rVg= X-Received: by 2002:a05:6402:84f:b0:5bb:9b22:68f4 with SMTP id 4fb4d7f45d1cf-5beca59a339mr7451139a12.18.1724083523048; Mon, 19 Aug 2024 09:05:23 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> In-Reply-To: <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> From: Linus Torvalds Date: Mon, 19 Aug 2024 09:05:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: David Hildenbrand Cc: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, mhocko@suse.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9C16412002E X-Stat-Signature: ob14u5p5ky5opqc63gh5gofazedrpkjt X-HE-Tag: 1724083528-521068 X-HE-Meta: U2FsdGVkX18fP+v6ZxzDUdj4WdOx79tmtSa+edpXqxVUTFoaQrNXZZbzgtjjvMxqaIQAqW5CP188pTV9L41kwzfXWYbrA3NZ9rxkyGukJwQ27DJMwewtqY92oJeLyptBI4j+olE/+NGRQLfH/zKexvub/WFznY1IERlKFxCKXPBIUJDbrmTnM3dC5q9gVgQOb1frT+91Ub/JJYPO+WbwCx2ByoObzLtSmgbDGsM4Z2/hNjp3Ii9sPOLjNJVOJlLJDNdrXff4F3Gpo5er3OXm882BrwsnDcTZ5Ppx5x13ugKJmLYjJTPE4kNr9B8ipnCRUqGygrCClSWxRKtbXzYFtSj6PFGUfT/YxZlSEsSApvYyBcZzEk29DDLCd7BJXi3tCzj3TZfoLUMMlAHJ4p/L4wjU8+qMHhfCEUfWvK7/nm71TupVaDp52z9Y4rH+UOz78+stcF2hYZyRDWltZOr6QUoZ/oHDUJb8Balfz03NxTsFfdItRRohSJ1KAC/BZII8gCBcmqxlcucxfdyBxSQYuu0beGJcsD04gpEGy7JKRAPjcwVZwn0uRuGqbJURZ6eFZNjzfddEw44ZBKLC4HGaDiUjAq8Ytzi8QtkCnZSjbDTTiR99pPz4uZKNOjdjEsZ+ksi0bOwgPkqAtE5L+UikvLKeCcLqS6pJ9asCAnxYS+AgH8xz4JJFZTHGVuqkRG3ub1xyd1FwXSM2KN2JzNP9SvPDOrs0+WdQ8JRmbXRYh415xKJPs1O5aTTKXfaMnUJIdvBRQncKaUWHeeQQHK3mWYBnIVmP929Wdg1gX7jB0L5XhiQUdy96gqNqTX2BH+rNgM2/VuO3kazswCqfMnNIdX7S8cQY395jiATba7N5k9EOS+k7DP5ZHz3Es0Q6OZyHx6DIbAl8AnxHjop4AAbpFGxTYNN+bWote4Lx1sD5Wy2fI+ghvQU2xnNBXhOfhCgTta/0rINcvzKDNL3BHIx NGq8PFUg E1Oa1SbvSx+PNYnnZU4kyVOQjbX/FEEUUGTZ3SFUAImG5WgJhfL0foeCfTkLe/qTZ783/0qPLVJMdxPdItfH5ueDr9c9igqBXXLGiXgBnVTxVlhhDmzOfHB0nVbylxgij/HaOQ80cJJKY7yKqnS884IM1M2ScRZxlkmNmuT/9iLgxtuFISiLyV4ScJu3FP7nq3McmkPKV0fjED/0u8+e4BkLLVorz4gAH+HUfJ1Pih9IzRZ3iQC3xXVOwqzNJpsFCqPmlky02aBlMc4bhBOxOJaRrjHUJ0aH/gbBrHjKjPHROKxKFqKnTezv5lTX7iMKu0KOCNtfuOpRWYvbXSl7r3xEUlxl50uI0cz6hmaX8WYTa9ckuI8ROerMn6ujn+CJkfEJQyk/UpEVqZ/nK5ZghV6zKODk5O9E2Q65kBDppvXpWcwE46ZQASSNYfvtlNBlRBOttJWBqseZzz+qH35qgF6nHMSL+3ANofT8dva6r5iLEfv4ed2tVMbZPjJ2b4YE7q00FUyOgxuGef//Xv/hfwamDEtZQ9tK7KQ+eH9t9ewDbAjHNnhQWLfHiA5zmOyyG2gwPMaBwgdPSiDd82Sd7UhsG5tn9oBlfbCNofjSm3MxJ9GrWtZ37cOezO9VGLN5x30ip7EwNIboVqPU= 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, 19 Aug 2024 at 06:02, David Hildenbrand wrote: > > > > If we must still fail a nofail allocation, we should trigger a BUG rather > > than exposing NULL dereferences to callers who do not check the return > > value. > > I am not convinced that BUG_ON is the right tool here to save the world, > but I see how we arrived here. I think the thing to do is to just add a WARN_ON_ONCE((flags & __GFP_NOFAIL) && bad_nofail_alloc(oder, flags)); or similar, where that bad_nofail_alloc() checks that the allocation order is small and that the flags are sane for a NOFAIL allocation. Because no, BUG_ON() is *never* the answer. The answer is to make sure nobody ever sets NOFAIL in situations where the allocation can fail and there is no way forward. A BUG_ON() will quite likely just make things worse. You're better off with a WARN_ON() and letting the caller just oops. Honestly, I'm perfectly fine with just removing that stupid useless flag entirely. The flag goes back to 2003 and was introduced in 2.5.69, and was meant to be for very particular uses that otherwise just looped waiting for memory. Back in 2.5.69, there was exactly one user: the jbd journal code, that did a buffer head allocation with GFP_NOFAIL. By 2.6.0 that had expanded by another user in XFS, and even that one had a comment saying that it needed to be narrowed down. And in fact, by the 2.6.12 release, that XFS use had been removed, but the jbd journal had grown another jbd_kmalloc case for transaction data. So at the beginning of the git archives, we had exactly *one* user (with two places). *THAT* is the kind of use that the flag was meant for: small allocations required to make forward progress in writeout during memory pressure. It has then expanded and is now a problem. The cases using GFP_NOFAIL for things like vmalloc() - which is by definition not a small allocation - should be just removed as outright bugs. Note that we had this comment back in 2010: * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller * cannot handle allocation failures. This modifier is deprecated and no new * users should be added. and then it was softened in 2015 to the current * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller * cannot handle allocation failures. New users should be evaluated carefully ... and clearly that "evaluated carefully" actually never happened, so the new comment is just garbage. I wonder how many modern users of GFP_NOFAIL are simply due to over-eager allocation failure injection testing, and then people added GFP_NOFAIL just because it shut up the mindless random allocation failures. I mean, we have a __GFP_NOFAIL in rhashtable_init() - which can actually return an error just fine, but there was this crazy worry about the IPC layer initialization failing: https://lore.kernel.org/all/20180523172500.anfvmjtumww65ief@linux-n805/ Things like that, where people just added mindless "theoretical concerns" issues, or possibly had some error injection module that inserted impossible failures. I do NOT want those things to become BUG_ON()'s. It's better to just return NULL with a "bogus GFP_NOFAIL" warning, and have the oops happen in the actual bad place that did an invalid allocation. Because the blame should go *there*, and it should not even remotely look like "oh, the MM code failed". No. The caller was garbage. So no. No MM BUG_ON code. Linus