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 1B3CAC52D6F for ; Tue, 27 Aug 2024 07:16:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A801C6B0083; Tue, 27 Aug 2024 03:16:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2EA56B0085; Tue, 27 Aug 2024 03:16:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91D896B0088; Tue, 27 Aug 2024 03:16:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 75C946B0083 for ; Tue, 27 Aug 2024 03:16:00 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 06104C1610 for ; Tue, 27 Aug 2024 07:16:00 +0000 (UTC) X-FDA: 82497166080.05.63B3353 Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by imf14.hostedemail.com (Postfix) with ESMTP id 3EC88100009 for ; Tue, 27 Aug 2024 07:15:58 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="BlKLF6/v"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724742861; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HfWuviBxFJfV58v2V14NBfJBOrU5hN/q2Ap2CVzf5/M=; b=vRbREzRL4mHINZ9n62IVet1EpCr8jRaXw9OWiZMJ/b5z9t0iiuotzinArj7xPybJueRjXo rPLg0dltlrtkkDhb1UlMTibtJN6Glz+YQkJlujp6mkT3i9Np7buh5iCywKwPR12NpzJ2dI naXYkVa+6fYLeSUHZqgqR2GnhgoG7Fg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724742861; a=rsa-sha256; cv=none; b=5L6fDT2Q136M2OArGUvrWNYLp+fzAdSpKQpKhFMdJjSP9tEeiG35fZu19CM+zIUeRsbyG0 E+xvPWkxE9ufyTBZY0wluvYjl782IYapU0VaDxPUS3nr4rCXXHXmyzyc93iXbHpuUEQAgM QcSMnzX/zbAJEg5hUy7lBkyU7nNQn7c= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="BlKLF6/v"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vs1-f45.google.com with SMTP id ada2fe7eead31-498e40756baso1627316137.1 for ; Tue, 27 Aug 2024 00:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724742957; x=1725347757; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HfWuviBxFJfV58v2V14NBfJBOrU5hN/q2Ap2CVzf5/M=; b=BlKLF6/vOtcIx/Ii8W8qk/0uJpFfbWJKwrHBPkwzR4oB8J0XLwuj8c5oShuxztOsql 50Hff9J9gnLPvLA3/cxxXalRFreeOvVpvOtZo6OI9jBMWqvSFECtkNKHnEkPSNikvtq3 D5n9fQgz2EHyJ8ly4gLDL8BBefQW/FKN5LZlzIFMW4K+GEQIrcH6gNp4ZNjphJYmWAyi dQp51DmGkigJzNF0HdYUUv7HAVT8TRaiNQOE16n0OiUJavLEQS8QtskciRK9CIKDa75d UGKru2tv/Qj7zg4VLnRcL05XqadfjWwBQ7H3lrcePjsPdPxJzboPxE4Jht1Nae94jvod eyZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724742957; x=1725347757; h=content-transfer-encoding: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=HfWuviBxFJfV58v2V14NBfJBOrU5hN/q2Ap2CVzf5/M=; b=dddqyG5Cuewusj0cUrhJeeXHh/TLgI0OF0xF1gnOHz8hc40wug91BulZ6P6RG13a8p hzrMVb9oCWZ5Tu1hJj0LmA4qXo2YoVCkK/gVkMBl4a9JOB3dU60Lhf2sUkmQHJyiAya5 BCA3wRVdDqzHwNMxWHE6X46XStRcFuHjITeZQq4kC5Xhi5TPir3mbl+Q1XHUvkwwf00S iyQq4ugCdQ24mfIJjnNgBesUB0kiIW/VHTbnQcM5hA1CZqYzAtp7D+NIMSrqJqUzv30U tZLW2SUqZhkY4COZj41y9Bz0BH9BhL85cPWDeAyD/mWYYBK6NaqHumIrc1Wa+PX/zOf8 sTog== X-Forwarded-Encrypted: i=1; AJvYcCXlIpUDp2Uh8JdLO31r8ZDF+S4wCuTcfUkToRYNiX8q4YSn1I3UrBeEtkvZ1gyVXl+9+v0XnJ/AgA==@kvack.org X-Gm-Message-State: AOJu0YyG97MTZZMdC8IesXlzQ6BsqF8udpMoZsJVrTXyIht9q5HIVq74 bARx8K3cA8nehkcBKBLmTXkfJlyxQ/iH4VGDtN3tRkjP9TBYfgo2k6/iwOf0mywrJl4rHDcT9G3 1Hm6n/gw3gJyoeb5d9wc734NOHQk= X-Google-Smtp-Source: AGHT+IFOMrdGBPzB/Y23gbATO0KawTPc/T3RLt8h6VL3XTl25KGI/hvLQkpOjytPsxTrJiKvX/bCPttzTgY8gG++yNU= X-Received: by 2002:a05:6102:3051:b0:498:ca87:ba49 with SMTP id ada2fe7eead31-498f47008ecmr9632852137.19.1724742957164; Tue, 27 Aug 2024 00:15:57 -0700 (PDT) MIME-Version: 1.0 References: <59e90825-4efa-4384-8286-06c0235304dc@redhat.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 27 Aug 2024 19:15:45 +1200 Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Vlastimil Babka Cc: Linus Torvalds , David Hildenbrand , Michal Hocko , Yafang Shao , 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, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3EC88100009 X-Stat-Signature: z9ccima63mdka6goufejcf68xsmoac37 X-Rspam-User: X-HE-Tag: 1724742958-278276 X-HE-Meta: U2FsdGVkX180C2WfVEKVJpEANUm8LLCVtg8VJqkrgqTbA2OjcaFINFWAargZuAcAemduEppROe1EXZKRpbNFmp6q3l6t/HLwuJ+Ez6RTRQY4v+3THwASfwupMhLWQuChbt2XilHsZGr8zzhP0EoXz3GAJRWZap9o0hVz0o7HYcXjPmQo17fHqAlRIeojDvtmIhF0VGLmCXUVNZgCqufsbfoD6YAWR4/2g7uipn+EYujb09f1iDFsbB5MeO0wOEtEYOngo/axRGpqpzjKyZWmoF0ccDMjrberyzhULTU+zw1iWNXnndpSzgUlRQRtudQd3xTw0mn2rmQ0dV751rjVRqbVO2/Hj2KyuUe+oUohDuuE0gy4kNE79i3o7lSxk/YTIsXJs94iSbVc8z2V3tFCw047JSl9OnNUXpQ1B/hBacgMmh/oKc0rGSAsERlsWgwVBGZuiCrD6Rw+QKWfwAVuPo9o6q0vQrHhzZ5RyeRrgyXdS3QIIaJKZ6bN+1UkMLpd9FVeepa5GISo6t2ez0VNeeRlSHPCnMoawfCzAQZlCydQ1wrXwoEXwcgo1BLJFACavjPena/eSHILbDHRBPllRr/ZVZPbEt570BpioArtHv42ByqVLiIVxUtpchF1VVwSQnEVWmsQm+f9P8xFKz+vrFZPHSGzr/DVqHfuRgnzJLFIxRT8W7BwXlztY5bOtRkVV5najcPFUkZWPkHGrZ4oWG3WJXXYaLsnXYlHQ7/oF4wU0tijkYN+wy7sYybh5nfL4AH5YqUunO+cbUaTiSuzq+1nve6WUhwx1Pw2M8zNdslYlpy8OAJb+bfSCIr1+gR0RuX+vf606FgMaVHfvDcI993MaFsjnQDzsSjwhy/E4lpXocAgS4UKXr6iRPygUHtdTuSRUYFaHAb2lcvlHy673e2RjjlC2tHoULCfbAbCz98T420xTVBU3F9ITgQYs7Y43I86uH3ENXFvmrX9Jeq T9AI1mlx gMljtAYgdqdxZRcf6BafGTCMoAD5sepqTAq3ELHukRMXO/ehAyF4ikZC4FB1kZc7+ydoM0NiBVA7RlbGbpCiGo7ioouBb//9yPMTGyjoYZSgN+9/EomeVwLI/YN5oPbnzAYx6AZBpltiFABldhq9ER6AEng26XN1Cf865f6XDya74nVWwAS0m1LlCpyMpTTKG1zgNz8PFLGi/FrLYc1Ag4Gw8SkZNe2MwUYYF+O2e8MzYN7sfEq6fiFS3gWq180PStyw92MqryQitoC3OEy+irnaVZoFr5KhAd11tWbInKby0oVz5VKxQeWIH9UTTuFP6TMU0CA/mUIQ2svNh3BRIgINH7hOHTi6/63/fS1le5fusfHDt5Ra8UySNyP+rJ8VGS+fMFUY2e1irwhU= 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 Tue, Aug 27, 2024 at 12:10=E2=80=AFAM Vlastimil Babka w= rote: > > On 8/22/24 11:34, Linus Torvalds wrote: > > On Thu, 22 Aug 2024 at 17:27, David Hildenbrand wrot= e: > >> > >> To me, that implies that if you pass in MAX_ORDER+1 the VM will "retry > >> infinitely". if that implies just OOPSing or actually be in a busy loo= p, > >> I don't care. It could effectively happen with MAX_ORDER as well, as > >> stated. But certainly not BUG_ON. > > > > No BUG_ON(), but also no endless loop. > > > > Just return NULL for bogus users. Really. Give a WARN_ON_ONCE() to > > make it easy to find offenders, and then let them deal with it. > > Right now we give the WARN_ON_ONCE() (for !can_direct_reclaim) only when > we're about to actually return NULL, so the memory has to be depleted > already. To make it easier to find the offenders much more reliably, we > should consider doing it sooner, but also not add unnecessary overhead to > allocator fastpaths just because of the potentially buggy users. So eithe= r > always in __alloc_pages_slowpath(), which should be often enough (unless = the > system never needs to wake up kswapd to reclaim) but with negligible enou= gh > overhead, or on every allocation but only with e.g. CONFIG_DEBUG_VM? We already have a WARN_ON for order > 1 in rmqueue. we might extend the condition there to include checking flags as well? diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7dcb0713eb57..b5717c6569f9 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3071,8 +3071,11 @@ struct page *rmqueue(struct zone *preferred_zone, /* * We most definitely don't want callers attempting to * allocate greater than order-1 page units with __GFP_NOFAIL. + * Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, + * which can result in a lockup */ - WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); + WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && + (order > 1 || !(gfp_flags & __GFP_DIRECT_RECLAIM))); if (likely(pcp_allowed_order(order))) { page =3D rmqueue_pcplist(preferred_zone, zone, order, > > > Don't take it upon yourself to say "we have to deal with any amount of > > stupidity". > > > > The MM layer is not some slave to users. The MM layer is one of the > > most core pieces of code in the kernel, and as such the MM layer is > > damn well in charge. > > > > Nobody has the right to say "I will not deal with allocation > > failures". The MM should not bend over backwards over something like > > that. > > > > Seriously. Get a spine already, people. Tell random drivers that claim > > that they cannot deal with errors to just f-ck off. > > > > And you don't do it by looping forever, and you don't do it by killing > > the kernel. You do it by ignoring their bullying tactics. > > > > Then you document the *LIMITED* cases where you actually will try forev= er. > > > > This discussion has gone on for too damn long. > > > > Linus >