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 AF9F6C3DA7F for ; Wed, 31 Jul 2024 11:31:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 275D66B0085; Wed, 31 Jul 2024 07:31:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 225096B0088; Wed, 31 Jul 2024 07:31:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0ED806B0089; Wed, 31 Jul 2024 07:31:08 -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 E4B4A6B0085 for ; Wed, 31 Jul 2024 07:31:07 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 946DD4029F for ; Wed, 31 Jul 2024 11:31:07 +0000 (UTC) X-FDA: 82399831374.27.E176C01 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf02.hostedemail.com (Postfix) with ESMTP id 92DB080022 for ; Wed, 31 Jul 2024 11:31:04 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CtkeTOa0; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722425460; 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=UBCJFgeTUdNvJzWxqgzbqzKW7GxJNF6lw09ytvxv+Fc=; b=8R9WHpXqKAEo27B0SHbrkBuWbqUe2ZJlNgjxT/Fz2qBi5L2K1zhypG8vThki/4d9Inptv/ 6lXdv2Po7Tz08Q8lcvjIe5HX7XDmEhgqnHjytQa2Orhj3lYskFFLTTx3oHZiiWRNjjcxP0 B00xk1aNxqqxSwS2LU8fh2HDZA5OQeQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CtkeTOa0; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722425460; a=rsa-sha256; cv=none; b=5W4qazP5RW7sswz7npxz6SK+CR7ndp3VYcp/XC5nWUUhKlGH8QEdnwRYeAQfuvtygtiO5e 3lI+ClKWm4+vaquTPZo9bTLlYrFO5vnKqQhZV9FKc2I8EQzfj5rfB6nXk5Qkhmj/bx8Xmq iX9296pLQiZk7is9dKmxwNt99vgRhIs= Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-42819654737so30879145e9.1 for ; Wed, 31 Jul 2024 04:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1722425463; x=1723030263; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=UBCJFgeTUdNvJzWxqgzbqzKW7GxJNF6lw09ytvxv+Fc=; b=CtkeTOa0W8nvPSK37Fl1wFmRlmhlqyMAfw+OrUjpFaNQsJVDgHJ2785TpYnc5xvTwX 5p3KemvpSDZGhA7m21FM9yiMK525jzu8khI+xYuX8hamNnW+la/3sKhMo2dICUkJwaBf N0ZR1rUIOWBvjPdfglAWkWWswgHiokPdHt2suN6wX9GothTfn/Qpa3ACH597xl2RwOOG tdpMQ+ITQO5rsYm/Z6lgLlyCDHKODIER2ehw2kg8NDQdrjSa7Lzse8Y8q38fS7/ZpEuV kQVKaYmT1zbLDN77PfQiRoFKJZXwK3XE1OhIluZCkgk2azBhTL5n8h44VJpF3owjNbMB 4tVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722425463; x=1723030263; h=in-reply-to:content-transfer-encoding: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=UBCJFgeTUdNvJzWxqgzbqzKW7GxJNF6lw09ytvxv+Fc=; b=MIyEkddTfVaFJFOGst9gqSD+soVhJQgwfzw81HK8u41VZbrdECeGv7LKpNNHqzfsX1 hAExekeiO7cvRlnooepdhxtO0sgFWwVIOPT6ImpvfcnF4WKh5rvsRI24PUlD+5GPzHp1 Xdj1ZzRDg9gZFjFYHcxs1geCnds7QtvSmEMTENfXz9KlX+ktooxqgIHy/Mvdt2huzGaV wKUo0OnXD9PXJfS7pe2BCyuOQO5Dr8adXsTCLcT6HG7G7Y6H5zIcKI+psCj4btxD/geO lJpXsZkf2OwIbWgTRrQggbipwXEgRQ6v6BiTeSaBSmRqKqIC8JG1wxoQDVyxwgFEGpgx D3RA== X-Forwarded-Encrypted: i=1; AJvYcCXavcx8sAu2bA8wgO6eS1dffRbhM0+Tpex69tM5gxDHqAde4LI7WN571O/q3GLUjcjUuJM3vmdfhumXlcBTt4aaIPw= X-Gm-Message-State: AOJu0YxP6C8abzp/ZdEZUITq6cT4sl9JW46T9X/DkNZwCrLVGL1Vxt79 8/8WHppLZLn9F9A5zRrZnSYFCgKypi9Slwz+fbw1k/6B8/t61jOaoC1zLi/Ta+Q= X-Google-Smtp-Source: AGHT+IHLboSEXgMqcN0I7NYGtzc0ZydEJ9mpuueEUQiRZIu5xSUHLIfmpOCHl7eQFU6uhiYGogiWXQ== X-Received: by 2002:a05:600c:1da8:b0:426:6ead:5709 with SMTP id 5b1f17b1804b1-42811d8893fmr112316335e9.9.1722425462898; Wed, 31 Jul 2024 04:31:02 -0700 (PDT) Received: from localhost (109-81-83-231.rct.o2.cz. [109.81.83.231]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-36b367e515fsm16851308f8f.45.2024.07.31.04.31.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Jul 2024 04:31:02 -0700 (PDT) Date: Wed, 31 Jul 2024 13:31:01 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: Vlastimil Babka , 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, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev, Kees Cook , lorenzo.stoakes@oracle.com Subject: Re: [PATCH v2 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL Message-ID: References: <20240731000155.109583-1-21cnbao@gmail.com> <20240731000155.109583-5-21cnbao@gmail.com> <19981556-cecd-4f58-8b3b-bc3bb85a6ac4@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: h3pi9ag4739uxcdzzaq5zhskgp8g8iki X-Rspamd-Queue-Id: 92DB080022 X-Rspamd-Server: rspam11 X-HE-Tag: 1722425464-990747 X-HE-Meta: U2FsdGVkX1/JkX+uy5ZCbfVrxs4yPkcn8Ow6IZMLeZj3oulwblRjlMvy5LX9LOzeVYo/+xVcoQzb0K/C3FwDJfRHSDpDSGCYHjVabJWTKnc4/eQxPPiIjgiBQ7EiDiXvJUrgFK8oPJm2H9dXe/hPTr9bLYUzxpKef5glWsR7M+Um4j1g0WxzzckgKOGLxzzsZHp8/9OR9MQkXSNhfpxaRO+0ImBPNPyoQe/tL8RbYYF7rCkZtyBEYPG3C8RaroavbFJ0gUGWJ/U+84N3n6j+xGS4M+bGDGEAu7P5mckwuMKBiSaBpO67vg8GYvNG5lg58hxggF0qJaMb7GJPIJogQhS1wsmeYhPCX0FjJq88TAXjjZU8jnLb+2TDxCQ7WiwlWBFVK6IESDfAr9TjuZk7oY/OfM6jezIey/uZt6C2xowg/zEBFbr55gBu8xs0ckLv/cgZt9ZswzcieTLSUJbMwlG/HZSA+HoLOZbXArwRkPdC3FRrTLJByi6A+03VleGAxKkJKkdbG6orEN47ku9djbuTpeHjqle/rIyW2LABrNX9DgdfcHBzmoeDK9wEEPpTdnmOY5HUH+xp7M7GOGQqPBf4B+FB1guI3rYcZ5NDV0BCaY36T0Kh2zhUsooNPSxme3WG/HbF86aFCCgjOqjjrorZZxLyNgGSVyCRuAEG4Bvl2yBL2XnKvZCRmR+JYg6EXLN4NlpMf+bCjIn3mn4B81f1/93KiQlepiI7JRiCMtPcfc6GbJSDCZty2p2jeFo67e5kYkm6YZYkErlsVwNGRbLNmUfk7vrm3J+pu0uixpce0MBe7F2VUOn0Qyc5/gS+qelTrPZoIP3dvMgdH16u2gzpAsheXExywbw4iVAveWGj7dd4p5ebyvc8sC8+42NqlGQZ4GzSEWzfpWIE1pcrGbcQNIjG0b5PN4S8zy5FyAdJBN+UXzfb5manGlFrmoOoUb0SvEp2pL0J2U53C48 KQ+GcNwk vDx4iaRZ6yn+9c3VT7kIFvukpukYs6AQYYAbMqYVYjMf6+QLngpdFfRM5KCPzx7ij0P18x1aOiVBF7Nkd5kKajez5b7PP1GxfFAcTNTjbWYpoebhZ3eYXvS1MnnC95wAKcrZM6SKb3QRAH3QN8Kx7DWwm9+/+hr+Kl5y/PlE2PJArxtED/sZr9U+p8lakWty19KByoEzvrcwFKi7Mil+0Cv3EAhKmowHL5+vhPr1xbenf5joD6k4JVLE3S5x0UcZnhaiYZDIUFIKv7wlsjHiSewuNST2H3THp9Qvz0+xExOS8gQxHr2IH0MQsmZEIWyHm2KQLf0GzE5UohyQT+MooR9pPSdN5+W6RrrxBPDdUnYWsMA3jqMIaV4LvW9uRJd5zNVZ5XRYExlUWevGW4R5exj5Hr7EMAWVJ3MoPxV+2sVOJwJ44ldtt4ne+WygG+HfL+HwRPldCzhbynvAPLzuGUzSoEoHfjXaOmh+4WBzB70nfeR8Tz20oQH64+nacsBD3cRcuxv4KTUf+9Os9V+/hBw80X8A9qyRup8ECoEbFhVLXcw5+5D549Zv6lWEV4vSTdIZr9/HRfWdJNmiP0Bm3a8fM6wBUVDvh7tiMOuasez5CDFbWmhrm/vvpGQdjpjueL7ueWUEdGBpV60O6BV0eYU9mG0w5iN4S/Nb4w8IZAzRhiLPSynw6DK2Uk9fbtyLH0r6QSNOwgpZB7+KbTmDHRs5uKtqaeSTm0ZWQ6gNfF0ZUEw08Q4Mt9Hpw3lNiUOjPFp2wVP8TYxQmt2F8zuylAvxQUKNNmPGhZtm0NOxmPX8djcVJxevn9hzdBqS4sxUvHy1jkXPmYAM1MZ6f13FLqqU8iQDX+BDkrrWNI8T0r5a5A3IVXtMCPArXqsTlq44n+/6Q 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 Wed 31-07-24 19:08:44, Barry Song wrote: > On Wed, Jul 31, 2024 at 6:55 PM Vlastimil Babka wrote: > > > > On 7/31/24 2:01 AM, Barry Song wrote: > > > From: Barry Song > > > > > > When users allocate memory with the __GFP_NOFAIL flag, they might > > > incorrectly use it alongside GFP_ATOMIC, GFP_NOWAIT, etc. This kind > > > of non-blockable __GFP_NOFAIL is not supported and is pointless. If > > > we attempt and still fail to allocate memory for these users, we have > > > two choices: > > > > > > 1. We could busy-loop and hope that some other direct reclamation or > > > kswapd rescues the current process. However, this is unreliable > > > and could ultimately lead to hard or soft lockups, which might not > > > be well supported by some architectures. > > > > > > 2. We could use BUG_ON to trigger a reliable system crash, avoiding > > > exposing NULL dereference. > > > > > > This patch chooses the second option because the first is unreliable. Even > > > if the process incorrectly using __GFP_NOFAIL is sometimes rescued, the > > > long latency might be unacceptable, especially considering that misusing > > > GFP_ATOMIC and __GFP_NOFAIL is likely to occur in atomic contexts with > > > strict timing requirements. > > > > > > Cc: Michal Hocko > > > Cc: Uladzislau Rezki (Sony) > > > Cc: Christoph Hellwig > > > Cc: Lorenzo Stoakes > > > Cc: Christoph Lameter > > > Cc: Pekka Enberg > > > Cc: David Rientjes > > > Cc: Joonsoo Kim > > > Cc: Vlastimil Babka > > > Cc: Roman Gushchin > > > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > > Cc: Linus Torvalds > > > Cc: Kees Cook > > > Signed-off-by: Barry Song > > > --- > > > mm/page_alloc.c | 10 +++++----- > > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > > index cc179c3e68df..ed1bd8f595bd 100644 > > > --- a/mm/page_alloc.c > > > +++ b/mm/page_alloc.c > > > @@ -4439,11 +4439,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > > > */ > > > if (gfp_mask & __GFP_NOFAIL) { > > > /* > > > - * All existing users of the __GFP_NOFAIL are blockable, so warn > > > - * of any new users that actually require GFP_NOWAIT > > > + * All existing users of the __GFP_NOFAIL are blockable > > > + * otherwise we introduce a busy loop with inside the page > > > + * allocator from non-sleepable contexts > > > */ > > > - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > > > - goto fail; > > > + BUG_ON(!can_direct_reclaim); > > > > We might get more useful output if here we did just "if > > (!can_direct_reclaim) goto fail; and let warn_alloc() print it, and then > > there would be a BUG_ON(gfp_mask & __GFP_NOFAIL)? > > Additionally we could mask out __GFP_NOWARN from gfp_mask before the goto, > > as a __GFP_NOWARN would suppress the output in a non-recoverable situation > > so it would be wrong. > > If we use BUG_ON, it seems like we don't need to do anything else, as the BUG_ON > report gives developers all the information they need. It will not give warn_alloc - aka state of the page allocator at the time of failure. Is this really necessary? I don't know because it is "shouldn't ever happen" rather than "how come this allocation has failed" case. So IMHO a simple BUG_ON should be sufficient to scream out loud that impossible has happened and need fixing. -- Michal Hocko SUSE Labs