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 58381C52D7C for ; Sun, 18 Aug 2024 05:51:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE6058D00D9; Sun, 18 Aug 2024 01:51:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A95D58D00B8; Sun, 18 Aug 2024 01:51:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 984AF8D00D9; Sun, 18 Aug 2024 01:51:44 -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 7BCD78D00B8 for ; Sun, 18 Aug 2024 01:51:44 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 15D5740A08 for ; Sun, 18 Aug 2024 05:51:44 +0000 (UTC) X-FDA: 82464294528.12.E8D4525 Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by imf14.hostedemail.com (Postfix) with ESMTP id 4A0B510000E for ; Sun, 18 Aug 2024 05:51:42 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="QzliQ/Ox"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.161.45 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723960246; a=rsa-sha256; cv=none; b=q8/R5f2C15xJTcflHmOaN1Ssg3jfBz4l4estWv/9Ki5F9Y27CdeeAU604DoFq1wu3jOBWU fGTHSNo/Kf94xxf2CQivXb3k/ic9IVz8Akex+FgnHwfUtvycm9wKMkbSLrtFSLR0mxXfNS bPzG5XHXTKuxWVVUnYEa0pWPSuK1J2k= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="QzliQ/Ox"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.161.45 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723960246; 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=gIHCMVLYSWDGTFiX/5gV5EGGfwfZsiyvSNR7GSXZziI=; b=saSnYD4FaSRfFO7rUBket9dO/6hyCgEpXXlfk4wZCgHDI6Xj32IWLv/EG/6vgOlhdhCLJc m35mb5uoSXlLVUD4KML20WfLHYX2Uh4ZLFqwZSzoRTsVOcI9nhwEQSQRK9r5TdMUNBEKPt Wgb21a7Q/a4huqIcXtfwm1GvBlKlnH4= Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-5d82eb2c4feso2152708eaf.2 for ; Sat, 17 Aug 2024 22:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723960301; x=1724565101; 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=gIHCMVLYSWDGTFiX/5gV5EGGfwfZsiyvSNR7GSXZziI=; b=QzliQ/Ox/fP1RVe9aZdcskWXo6FTi9ra0spcm3dUdhpw+xdiELtMPJqF4MVoFufWXr Kvc5eKCW6GgeDWuIdsp4tOXAVZJHljZGeZ4nZLPXB1tXLWrSUmmC6qsUuXejTJWTNAIE Rzv1zg0aplnodcjjjJ6YqLfWHurk+70lMWmCwVu96D9KuJCuyFAUyUaQkNiiVbjc9+GX cL9C8ndR1sKhklkcqg8jnaxsUdSpm2elY74zz7vDV3x7BplMscKyxLyfV6Kor8q/873m MooJpEu12GH+ywr11VLyzpLhAPkwyfLYOJB7TEIbyw+kfL36sSOB1gUmhUxP8yZCE1b5 SDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723960301; x=1724565101; 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=gIHCMVLYSWDGTFiX/5gV5EGGfwfZsiyvSNR7GSXZziI=; b=rtUh+pCPmswhJAIy8mJMdwu8ytdi2em8dfSAqqAcSXapzHe0jrLV/py/tGj0RIKE1j g1EmzTehukKEmpTEMiRkE2bI/WpZX3XclbAgS9aeO4tsHdsuY6vz27PXqRonLAdsYu4M IDLNlaKAqgUltGQ730eimmITDXdXElrTMzfwWjZ8S9k6Ub6HcZxNwnDaHQx7STZGVAO9 AT3zeLHomQ3/lTGUFDLuuk8yN0QKBSbbWVBfxc/ShYgTHUGBv+7LSmnbajEk3xgRCKZT 4rHkbcnEjnBesWWma96Wx/9qd77zBr5yXB3Gcswx273+zE7smfDqSaO2/2u5aV4LS5IB YLog== X-Forwarded-Encrypted: i=1; AJvYcCUb9oNamlTM8hW24GAt3CXV0tUePk8ceEd7ZmYN3C/hzaD6Y/NdXnjixNG1LPDsKj/jTxqpWtbtTj1Juy9dzFMZQ9c= X-Gm-Message-State: AOJu0YweHJkgc8n1lhdUczeIkwPD/hAWk6KwSNvmljD2bLh1P+q6yJcl U80g/L5dmXmH3ZmBldppQsHxfaIuixqkJY/4uwO1rTUEzbfceD8U5LqhCR/7lCOGJkth67c7t0K bLgm7gXb2cQmwS6YYJwDMplPrUz4= X-Google-Smtp-Source: AGHT+IH9swZscxh4sskHiB4R3YL/stqfyl/AbcynGeDKsMxPlP0B7CAHA/3mszIw/oAe1Ba8pf73ix3TeqtLAtUjnK4= X-Received: by 2002:a05:6358:599b:b0:1ac:ed54:224d with SMTP id e5c5f4694b2df-1b3931a52bamr960549355d.11.1723960301160; Sat, 17 Aug 2024 22:51:41 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <20240817062449.21164-5-21cnbao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sun, 18 Aug 2024 13:51:04 +0800 Message-ID: Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Barry Song <21cnbao@gmail.com> 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-Queue-Id: 4A0B510000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ehwam7z3dorxg6naik96inmxt8txhmfw X-HE-Tag: 1723960302-689009 X-HE-Meta: U2FsdGVkX1/DjwsYKHZET+zfZFnthClNekHiOwrtjWxiNdUSJU7+PIPG2VYhEU2Bz9VenC+1+UsChulX+9TJyblxGXF2Va3Q4v6fZp8zzIItLUCJwsNjCRwLGrDEO4U7BxlKh1qXlErrHL86W21wt0HuSnu+V4vUcejdz5nMeFqgQwfzVn9FFlNsu23S4UdrVafIOunyHWDh/goMkZMtK0pmSXh0UsvgcUg/gdWiwCkv+zzFE/Z6wc/qdRaVp8C5zu0+EJRRmND+AAgD7/m73mYhjsKROtjS3qMZ8WjjIGj8mC1BwNfvqpUAOGoskal6NOE0BQ4X7m+6WPlawTzTZhadXKMzxzuT0gyjLSVg3oZVxAx/XSQTzQGyUyhM3pLvymUwOLDTSVG7qlZrm7oROLoqNHQChPrSC3p0agf2nU9wY8rzcMMYvlR+GKrIEOgfJqkGyZbGJj98kU1qau9ZOiwi+q0t8k3zkmw++YRp/WNJUw6kQc5MziIRcvqR8RUPBNinlbMZd410YSyNFSZpTMai5pcA1pkq8QLlyx4gO0oBCB+x11yYxVLPcBuukAem7QpbnUr7a3S1d9erO+f0HP8podaEGY13hWx48+FAh3P9Oy3F1CAn2ojTXoJwBxqO9COXqMeSkDiGFpY5GGreMm0WDYHoQigaw4XatoJDwgfXHhCbH0MQxdY6yB0rhcp0k53tue6XAmog5FT327ac5zjKJ8Srjli/N3u7OuEmH+antiEg8zstoRi/UZ5yul8R53I5mJrBrvdI1XCpbgPKHHsy1mOAGQz70U1OLtoMyIevoRTzgSpVSuZ7ArW+XtRjw1U2WYD9eNXesYck5ZYv438z15+Z+w9oQwbKuol5ByRYKEsGHfjia3imQAZ8p3LL3FHCz5AjdZ8v1XOpssUaHgGZ5XWXfgUweARV9lrNJhUlvNTYorZWZZhQWcbZinjacfMY4P6kMsXFAKjHE/X ah57/E4F UXN+S4g29Iz7wTB96u9Wf1tX+eLtPdvwdKWvEnWEFQlOgZ4Y33hb3EjMNf5itItdlNhegwPl1hVjkE29ZaN7PdIGSJBbJPH9J+OrHvtEOvfruguYIaJyiQ8eM8LC8Mifu5QT2J7T0VnpES6Vz/k5wGJyCLKqHE9anhT3LmtkmGYLq2wRO9wgDIopeZi+Rx6Y128M3oG6cIw3cIs6mbkXnBGU4Cwi6tQFIUQ+gg9hjJYfyYGz0HhQplYpOa2Zmubrw+k8OJ42ls/FFasiT9h8rSoYkYThYagUrWmpbsb1GQG6kOg+FqeVXDqiBR5dVq+32GSnBhoVm/4hlJbSvf0k4RJY/PXjkmDG8ZjaVfksifV21Igl0xHLmQ//gXEvBRUHt5qoNUigMBWXgRMEzP9g91NPMpqgsi3WLc7uklXnRM2k6HZ3n1Ix98O2LwSt5D0HYVY7O3oz5VKVdKc3DuG3fP2tM4B4HmSotL8nGExNgR+osba3AhZRJh5egeDY39y2Etk5fa+gRjL0EfjjcCOogJtsOQ6VeNgS82kkFlONW8BpgRAK+phGtatG8v8m35e5+Jrv5PHqeqa+pjUguFXm8vOlST0YP/gdIbQVNPpsKiOBSWwhhUBwS0jIK9qajbYDLjXa9xKTquemAa2HqDidmYOPWRFPqvWiXkDIeLTOEW3oFhSXaozBhgmAhZakFKggqrOcs1E3GCkzE4Kt1k9VUPEZb77vzd8M2BvCk2+zi/lIrKH+OzfRvy9OcYgE4xHdO8lhWI2M4TrhBFrf6yo1IpLbXCYU2KZuPxd+QQE41FHDRzlGCn49rKszo5afh7pXkTdberJEaypXhcCJtUgmnKwAC+ZHgynhXxsmPaLrz+ti533QC61t1dmXZJvB44klhl8/6Mgz8+yGm3sXxEagQo9Zmw7TCbDnxa9DRJB9lgbSnUa8ssWLZIt1nZKv3vbqHph5bEDAZeuM56IaUk9kqb1Cckk5m kszdPTmG 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 11:48=E2=80=AFAM Barry Song <21cnbao@gmail.com> wro= te: > > 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> = 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 tw= o > > > 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, > > > > 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 So, what exactly is the difference between 'constantly waiting' and 'busy looping'? Could you please clarify? Also, why can't we 'constantly wait' when __GFP_DIRECT_RECLAIM is not set? > 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, avoidi= ng > > > exposing NULL dereference. > > > > > > Neither option is ideal, but both are improvements over the existing = code. > > > This patch selects the second option because, with the introduction o= f > > > scoped API and GFP_NOFAIL=E2=80=94capable of enforcing direct reclama= tion for > > > nofail users(which is in my plan), non-blockable nofail allocations w= ill > > > 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, unsign= ed int order, > > > */ > > > if (gfp_mask & __GFP_NOFAIL) { > > > /* > > > - * All existing users of the __GFP_NOFAIL are blockab= le, so warn > > > - * of any new users that actually require GFP_NOWAIT > > > + * All existing users of the __GFP_NOFAIL are blockab= le > > > + * 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); > > > > 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 so, you have many code changes to make in the linux kernel ;) > > > 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. It's on the slow path, but that's not the main point here. -- Regards Yafang