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 D3484C531DF for ; Sun, 18 Aug 2024 03:48:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24E576B00BD; Sat, 17 Aug 2024 23:48:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FD336B00C4; Sat, 17 Aug 2024 23:48:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09F936B00C2; Sat, 17 Aug 2024 23:48:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E0C368D00B8 for ; Sat, 17 Aug 2024 23:48:31 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 31816809AD for ; Sun, 18 Aug 2024 03:48:31 +0000 (UTC) X-FDA: 82463984022.30.2F6F90A Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf22.hostedemail.com (Postfix) with ESMTP id 70B1EC0014 for ; Sun, 18 Aug 2024 03:48:28 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dZ7EgUr7; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723952870; 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=RnZmf45fz3PM9gKoePM/MMyRox7MihfS8oHTnz5nu7g=; b=XiJHIFmNQTnCwwByRPMeJrQw1cZEwUR3Eb750DUKgsAbaAP1pYYsAHJav+pok60zF7O7Gx uGVGdKyZM8/2ijoxUIzsTkAp/jeeg4m0QpTGyj2UKh9yDZ8UlGqsBjLROAnvm9n2ngSgsf MCy1zxE7tawOlFYqh3HgWWi06vLjCCQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dZ7EgUr7; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723952870; a=rsa-sha256; cv=none; b=JGTbMLdQwGAnSONesWdmEmCadqaViXO2hAGRDJGsYAFESN1aJpRg9A6ErZoMPRxzAtOc40 teMM/Ut0b16AvQUU4m86wDprQXFgEJphqspFrQNJOQoMId5C3znNbcGIhXAnHMG+hcX9OR coOvO3I6nTsP4ZvAleOxvjTPHdTthx4= Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4f521a22d74so1029892e0c.2 for ; Sat, 17 Aug 2024 20:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723952907; x=1724557707; 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=RnZmf45fz3PM9gKoePM/MMyRox7MihfS8oHTnz5nu7g=; b=dZ7EgUr7039mmexWtiU4vda6sBoKoRQbKtmPq67VFbrzL5t9qtM9YKLG6SoPsGzrb0 WO91inEgsyfxqhZU+7J+AIB4Y+vMFll+QppQie+yInEi8iSuYCu/GhEzx4gJiKS0Yi9v y4mvOmFF3TKE5oUz7yvcSbtumHgHec4q4OT43XZzKeXhKLbAq5wihdy/iJO/Wy+lz1Jl bgV49HhfIJpB+wLEEm/R7PRHk3j00oHMDCY0ZGL5fPWvqOlw1ch8WFXcra7sas/b9oX7 EEJ13bzLu/kpQ/+UF0w/wZXu7t8lyzR2edBBHOH+p10VLcC8Z9pNmInNj/gdLgEgpmgP I5OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723952907; x=1724557707; 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=RnZmf45fz3PM9gKoePM/MMyRox7MihfS8oHTnz5nu7g=; b=CqiBiuH9CiJ2ViTl5E/T+6VYHjR06IkVtvc5iIxj+kXunD7gVrzimLsr0uJpnnRByJ HtzYEHGXZSlSAqfUpbAxEY9Vv9ZDIvhZvQ/wIVL4rAiIjGd6KWPHZboxeO0QArqXJiH4 Meh5hGUzNgY/bfpy10Bl562ZFkLgCeHA4pCpqg32GQexSi5zhcea9DMLUaI912RLQwCA QVXZxWiA/+2/4ylyvxLECfUG8oEFGYyQXlKHYpqh94lzN+eSEFbxIJKwgiz1cWm0HWZM TcMqu36YIQsOYFmeXiMN4TvequiqohTBcodhO+LAk9jqUSUkJFc7/Ro8lGBZCKKRSYcd msAA== X-Forwarded-Encrypted: i=1; AJvYcCU/XY6/RuxrN7eqj1YKX61HuCHFEMIJhiH8idfRQmo0rxo6ay5619iVSvJVTL1QnF6kDZdj8988dNObPrj+GcQaGL8= X-Gm-Message-State: AOJu0YwNw9qClDHGkAtyvdIF/yCcpxE32IeVC5q1eqK7nBXx+BtIe9kN zT+Y7rfZMHX9hmnMl+MrViQRyI4hQEPG+Af7grPIwzI+Gw9ZM1rD8rPT9IVmNFTPTJMbUX+IFbB WjoeH3HINx11kACITlX/98yXZs6Y= X-Google-Smtp-Source: AGHT+IF0vb8HaZxLXeN34r97OuKqCjfQS41R6la06AtydAkWgvADr91Ik3BiUM8rwXY2Q/ljZO39IxZNuxrCJJQ4Kqk= X-Received: by 2002:a05:6122:d04:b0:4ef:280f:96ea with SMTP id 71dfb90a1353d-4fc6c5fef4emr8869145e0c.4.1723952907430; Sat, 17 Aug 2024 20:48:27 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <20240817062449.21164-5-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sun, 18 Aug 2024 15:48:16 +1200 Message-ID: Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Yafang Shao Cc: 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, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev, Lorenzo Stoakes , Kees Cook , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , Jason Wang , Maxime Coquelin , "Michael S. Tsirkin" , Xuan Zhuo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 70B1EC0014 X-Stat-Signature: ztje6krsqsck8ucebcpxkq6d39358uzo X-HE-Tag: 1723952908-384262 X-HE-Meta: U2FsdGVkX1+704p95c2S/nq8mf/MjfEG7YvIJvrsuvh/UkvbPBG1mhyJlweJQJX2+kOqhiJAKcU0PoCHqkTeY54vfSdpeJxKYi29K7W+mskbXIRfYGYLDRO2cmPq+KhbAkgTCRSOHka4OcYhW4hNv7sGU0QFuvBxHmDtXiTfTUlskqMO3DnpD3VTmPMyPAy4nKC7yMx6Aryclog0kf4ZQPVn88TADHMGuBpkqhh1fhfmlzpTWcZmfxoZ9bYNOPTmldrtqS63vpsGK9fbnEUCz4YssrF6FC4w6u6iiOV+HOkkfnz5P0OsIB21Dbs/Q4JVxq3JCAWeqqRIAfRieEIrO0y9n7o478mOZ6fJtTOPaCwb13qOvqqp/4QLUpW96SPwvpzGycr1bIlVKny9Hvfe6fjR8qsaXIhtDMom6PofE3s6S/KvNW+bIbNtXTjHDWs3D46lK803opFhbadLguzNPYSvTRCWNN3pM8X8C/7sB0l2cy+STeLQ7mKnlwpihxVUPnupRCD4EJzF6Z3wt3voe3wBPq0WKssrYza6BDufr4fzBfcd+wkv9vsKP9sq78ATkruM8nWcD/WQsgmC1Ly9PQi/IFncXQkNthZIbbz2656I+rSUaoh6TGKYrasZY8wCpxxq6co0eSf8sGNWVLxEUr8kY7v5bUBsdUDc2dFiHwf/D2pnwRPwwfMhPIdcZKSfW6iZNPErf+4IooDK0utO/vREfDqhTbObSsXUpB9FwRkIy1+/xXpEOFrK4rC+CZsEbVwtkCZC+tiwWzgdTrXnkRAmJxjcdM9Pd++ihda8l66izKNLG91ohXW3XC6ed7YlQVzXkigW2IZQ+JBTYuiBcepIfRGML3uMD3+aAlvu1ACPmPoVn5J+CNS/kpTXrpoIMJS36BU+EoHjADHIzMussTcxHg54J4oqZv7/4JTRIjoL30KCvi466AJUT71cXugrz2QShM6IYlByuurSsiS KrnwNm/o gTN6kMXUIxxYM0lBMAsWHNDJrHGS2xTPV9MLuZ/MVBWGY6TcDqdA+BA6ZinE4HPZmlSH8oJEiSCuX0sJ//GrbcbRqz9D5P7R4ZchZvohbGnMm0WZY8ZsX8zwAE6oYs9uMnomqb/1A1n0kgd7onxYIZc1fY9fpo363GdqRnsaaDRt/10XRrj814kKXrKdSSJzu4PRF1fHd5AlvhsY5WBidLzG/Vs09y7dqKcyFr8ta5dO9z1HpcYv2o4MtR0ISSmD2naywfIgSmvb+YA89MxavSo3CqTfOf6SUS5O5bYPAt2IeZw+7NuajIF7LHPJBSCZZSXuqwKVmBx81NbX8giPDhRfi2MaX+ocWm8Rqe8bQUC11D4e4MTYYNwNfy6iEMNAjucO+iGgthAyrf8XCLc/mt1fLqafGmKO7RIJy0ZVVggNc5XNo4B7hkO0x5pwNNHIJOsavt7CoGRfvrhWZ/KFivkLm0CjmYIB0pwQp4GNtJaJcLS70IaU8Yd8yrhNNBzN6yXhPkZGwgAqGCP9qXcdyefEON5wNSJ7dqQi5VksZeLKtxb4dG/vDSdRIYG/WEP1hb9Qnj1cVGn8RCgqYT3+iT7EoLBpOrE00os8I5bc/4B7+kB754iitpCC0L3eL9rmA0WkaRE2dzz1tgOBv7zOMRfEbD7xUrgE0o+RYm0L38yQBxSIRToAQXuRZuYyFr5D+od1CmblCIo/DfGLO0JoSxxeUViPH34OnbWPQrABPqjYe/sZgJ1PLJbhPpRMdbdI0x2PWGp21jU3E6fCtRAeNtYFOGCmPa42sCXvsdn+o4dYpBqFAKC5r70u/cR3pLL+DpUnGucQrB9uit16P5KRePQXJ/yILg7b1pL58lcRhGf3OEj/tTZiwaMc6nOfhqO8Ojo2MATWslj59ThSKA98YPOAmpI+HTQG3FLlIRShrYOzTDUCFAbCy2IaK+6YmS9XNkFQb 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 Sun, Aug 18, 2024 at 2:55=E2=80=AFPM Yafang Shao = wrote: > > On Sat, Aug 17, 2024 at 2:25=E2=80=AFPM Barry Song <21cnbao@gmail.com> wr= ote: > > > > 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 o= r > > kswapd rescues the current process. However, this is unreliable > > and could ultimately lead to hard or soft lockups, > > That can occur even if we set both __GFP_NOFAIL and > __GFP_DIRECT_RECLAIM, right? So, I don't believe the issue is related > to setting __GFP_DIRECT_RECLAIM; rather, it stems from the flawed > design of __GFP_NOFAIL itself. the point of GFP_NOFAIL is that it won't fail and its user won't check the return value. without direct_reclamation, it is sometimes impossible. but with direct reclamation, users constantly wait and finally they can get memory. if you read the doc of __GFP_NOFAIL you will find it. it is absolutely clearly documented. > > > 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. > > > > Neither option is ideal, but both are improvements over the existing co= de. > > This patch selects the second option because, with the introduction of > > scoped API and GFP_NOFAIL=E2=80=94capable of enforcing direct reclamati= on for > > nofail users(which is in my plan), non-blockable nofail allocations wil= l > > no longer be possible. > > > > Signed-off-by: Barry Song > > 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 > > Cc: "Eugenio P=C3=A9rez" > > Cc: Hailong.Liu > > Cc: Jason Wang > > Cc: Maxime Coquelin > > Cc: "Michael S. Tsirkin" > > Cc: Xuan Zhuo > > --- > > 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 d2c37f8f8d09..fb5850ecd3ae 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -4399,11 +4399,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 p= age > > + * allocator from non-sleepable contexts > > */ > > - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > > - goto fail; > > + BUG_ON(!can_direct_reclaim); > > I'm not in favor of using BUG_ON() here, as many call sites already > handle the return value of __GFP_NOFAIL. > it is not correct to handle the return value of __GFP_NOFAIL. if you check the ret, don't use __GFP_NOFAIL. > If we believe BUG_ON() is necessary, why not place it at the beginning > of __alloc_pages_slowpath() instead of after numerous operations, > which could potentially obscure the issue? to some extent I agree with you. but the point here is that we might want to avoid this check in the hot path. so basically, we check when we have to check. in 99%+ case, this check can be avoided. > > > > > > /* > > * PF_MEMALLOC request from this context is rather biza= rre > > @@ -4434,7 +4434,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned i= nt order, > > cond_resched(); > > goto retry; > > } > > -fail: > > + > > warn_alloc(gfp_mask, ac->nodemask, > > "page allocation failure: order:%u", order); > > got_pg: > > -- > > 2.39.3 (Apple Git-146) > > > > > > > -- > Regards > Yafang