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 A2994C5320E for ; Mon, 19 Aug 2024 09:25:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C7956B008A; Mon, 19 Aug 2024 05:25:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2508C6B008C; Mon, 19 Aug 2024 05:25:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1183F6B0092; Mon, 19 Aug 2024 05:25:59 -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 E8DC16B008A for ; Mon, 19 Aug 2024 05:25:58 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 94D37C10DF for ; Mon, 19 Aug 2024 09:25:58 +0000 (UTC) X-FDA: 82468463196.20.728B637 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf13.hostedemail.com (Postfix) with ESMTP id C93C420014 for ; Mon, 19 Aug 2024 09:25:55 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=abNCQlc3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.180 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724059493; a=rsa-sha256; cv=none; b=yGN8TVSLKDh8FVEtNm440cnqTPZmoTFQooMLFObWHB7uSM5JJ5e+XdvCrz5I/qQ/YilsBG SFP2M1hoa8oDTcI2mIvjRO3sXpQUQjiwtqUOs8jM3CsElUstnoAev2Mvtunx0mFubBgDh5 rWhrgEwo0wFB5lq+24LJ+7orVdTGlus= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=abNCQlc3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.180 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=1724059493; 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=UjR5pvDEpewPhW0X2X4sJsK88Su+PeH05ej1TNllwx0=; b=2Htv2khwiiMnh8ZWkJTpYeScK0k+dQFWOF79bdhsHRBD1RNgVX8CMcU1TjG+WOmvofCgmV FG6oJl4CeJ1LW1+s0I8DblBDhFmzo2ZLxlzT8DScqXmN5NrlglWW4c0IqMQS/s83ERK02S enkuzMOtpDEABz+/a5g/fAd40Mo6SIQ= Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-7a1d3e93cceso488750385a.1 for ; Mon, 19 Aug 2024 02:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724059555; x=1724664355; 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=UjR5pvDEpewPhW0X2X4sJsK88Su+PeH05ej1TNllwx0=; b=abNCQlc3RvCAhcQg+aB77vJ8WRq1LZf0DH1782+7KF6LeYwncMLdAruzb4qASwNsUO hmLv0L6VJkgSqpJK3coAbH/iSFczGtEp1Y2wGZ4U3nHmilNGmYt2FgdBZG3LfEIqtm/k knymwl2nY2jwl1wmRckcc02+xyW0mxdqp5IQNjJo25X2dhm0ttRlRxoHog5kVGK5Ah/T Ba0gb2P4swmR2ksfpnZWZjgTHC6P5eUy0Tu8wIh85Gq3NJDcdx+Xv2+oBYRP+Nzf5SFG AmpIIr5ghv4qoDLiVUclGlc/ExgFviPvAdMlUzwWPdAMlvn2S/Lcuht8dwdK9MpMOaxf DO2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724059555; x=1724664355; 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=UjR5pvDEpewPhW0X2X4sJsK88Su+PeH05ej1TNllwx0=; b=VrHKEeL7cWeyoKWJNYOpt0wWf6DE//IuCdUSQmWBuHdWcB81vxsB3rVle9Y6xI00PM r8XjluMPfx5cZEp5fxWf96Xi0vdgEYEbzWAwzkp8ubSbptat3Diy7WIT1eqxjQT6lxW1 fzRMmt+jYeEmvhONtNxs2IuvzaBPdypO9q/fur788s8ZvxGewkYPkFHY8YhYHhQNSKmI ETDkYcvF2TqajqLMrz6EaYahyWNUFxLI+oC+u3WWOFyWlCOtJa266O4CDnnZnwOZ8Wlz rIL+FkNEtPx5H80QldJHz0uRAamfMmP3po89Dx+bOeBCe60qB8ckBp2Zy43M6z/lHppf ZwLA== X-Forwarded-Encrypted: i=1; AJvYcCWzRtalDuQwrVA3r19TJfaPQm7C0GcptbbSXv8c+RLUjurpw9PJhqL5wOwjTmK4VIamqHoO0+EglXJkR9eYXPVS68c= X-Gm-Message-State: AOJu0YyUtnOQ4vfK7XRqZe+jD9pe9ojrCDnbb7miMeci0uJ+kVsADBwE y6R48aL4TZpFd5T3TDYzmCCziJaflvxUDFEV4jmfQ+89oBCnj+D4HHoA9kgARzvfj99F+ruKX+H 9HySqCpArrZ+UG6fbpukUKqIsVSY= X-Google-Smtp-Source: AGHT+IHPX+AJBoChDZNdzQo1/ybCnjZBukhX7o88gEryvgpmzCLvhwLFJKnkwMrSIRJ0gr1ssNKoTOMaLGzCjtkY7VE= X-Received: by 2002:a05:6214:2026:b0:6b5:d90d:ea4f with SMTP id 6a1803df08f44-6bf6ddd2a8dmr275047936d6.15.1724059554759; Mon, 19 Aug 2024 02:25:54 -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: Mon, 19 Aug 2024 17:25:18 +0800 Message-ID: Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Michal Hocko 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, 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: rspam12 X-Rspamd-Queue-Id: C93C420014 X-Stat-Signature: g6h17aook1q36w9mhukd1ukgx74kpinp X-Rspam-User: X-HE-Tag: 1724059555-742101 X-HE-Meta: U2FsdGVkX19cKPtnLjOSeXO6SGwbWrYIv8ahRjPEHvPaijkPUn+fR7/do3to3h+trsag7E8tprRWcEIWbu3vNavc+nu4f+h62IBUUkiBXYxM/93j26HTsvW78+L4uuM6jYPLBN7a8Wf/QmbTaAiPt7wO7DJZSzY89iHqzfH3GH19cFoQIDM+Q/jdfgRb17xoQw4dnMMWgwUm0kqtIJkA9xasCepHZPYLOZE1wBhQdMHxCwxcijGhqdAOno2Q50manHsW5Sd03I4r8kHtMFtDxCZ0fgI40AVLBT2vSIVJE9sgb4q0+0lm7nthp+cSQ3dyTvXVHvwD+ZWawcqCnHFt5l8aAN+jC1g4vt80+VAa/SmsI+IFwLHAyY2k2SRTa5ZrP/Kr51DErTsT6FRjXmx1LxWQPHzAOcEydO83175N2saR5+abWdtBOmDUbhtnauNelg4w6QSLdbBC6TPClwRb+7LTIhj5R5wR2krtZQGT0SFZian6QxH67bwkX0Wx0PcKPPAy0Ab15jPeY+O+mEEAmHaHUym10HAsjr9iDaTSKzdezTiejwZ17Ik+g0QtbrOdmHk+5OvRnqz+wmGfDmI9JCWQDf4VynaGbbzKUrVHY2fjDAWXjn4BL+x2yNzRzJd8yj45fgJugm8RJuJ1Cv2oplZuxBON3ABRku0AiRqA40bbH7ygzzLppG+87CrlM6MDfrDWKpnBuOaLAkEqFEs2Ul5qFacjJlVvk89da50hceC/FNzLPwVY09QxwYloUApkLrbpaZfKjg9qbXhMsuNsVyELUGvqQZvTXsyX61hjwW/UCjBPuo9x+QngNqxHJ9a4zZDfavDmmtR9ALetu1lZF/W5i2PeeLr9dr1q0vyXJmS0SZil51kV05HvoTWPe+3yeqKBeaa48+AeCE36tf9R5NYrY+augHVnjsAzyCzeqFjD3pAB63bYMLdTNRbb2BYdO7W0yYW9D3tHqAv1VeO k/Eol6uy yVE3Xnoqj9EmzZzZ/B4YkbiYegCV60ANljwFatLP6NL8M4w6t88t1gZKJVpA9DfO6bWZyAcY7MynlNWFrk43IfgDFyem2OW+379YKGPEfW+myTQh7vthYzfdrmsa1TTgATxKhEkZHNxUuwd58Khu818INOns5JetT5oH1NaL4QgPhfibkXVo/zLqYOuFi004bMPfdGDxa8FAgcCE8lKX58WClKRT+NzsP1RU7V+LCIIvwopA0sJ9ZClZIrgNhbwswGOg2AXZvgbyIAw8WMdKXhjM00ZXuf7gStWWnNR7x32+rXb3TM+NiiXxspjkKLh5HLagfLnlNGGfDs/cL18XpdbNr+u8JbINFO4/8uY7DNLlD2mG4p53liujkMFjsRj32NJWZtDmSUgnbrsCPB9YPXKhLe0rKV3KIR1e96Badxuy0FCMXaqoAFPmNVp+W/GdYfNQC0LUiW9N4jyHgZlGz5du1KJPUuKp1KQ2Tqd3wDXyMfhfiGtbztd3DXzGxrwIWERSYm92+xg+7mpRMUZvhKXnH+pQoXKl2x4dAvTmj4oDbbhHV2Dj+H8avha6q+AbHRsWhJfVLRXLcLU+REJrpzaJQjw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.003936, 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, Aug 19, 2024 at 3:50=E2=80=AFPM Michal Hocko wrot= e: > > On Sun 18-08-24 10:55:09, 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? > > No, it cannot! With __GFP_DIRECT_RECLAIM the allocator might take a long > time to satisfy the allocation but it will reclaim to get the memory, it > will sleep if necessary and it will will trigger OOM killer if there is > no other option. __GFP_DIRECT_RECLAIM is a completely different story > than without it which means _no_sleeping_ is allowed and therefore only > a busy loop waiting for the allocation to proceed is allowed. That could be a livelock. >From the user's perspective, there's no noticeable difference between a livelock, soft lockup, or hard lockup. > > > 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. > > Care to elaborate? I've read the documentation explaining why the busy loop is embedded within the page allocation process instead of letting users implement it based on their needs. However, the complexity and numerous issues suggest that this design might be fundamentally flawed. -- Regards Yafang