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 3D697C3DA7F for ; Wed, 31 Jul 2024 11:09:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CCAC66B0085; Wed, 31 Jul 2024 07:08:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7B776B0088; Wed, 31 Jul 2024 07:08:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B44AF6B0089; Wed, 31 Jul 2024 07:08:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9BEB66B0085 for ; Wed, 31 Jul 2024 07:08:59 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 622AF160290 for ; Wed, 31 Jul 2024 11:08:59 +0000 (UTC) X-FDA: 82399775598.07.AC168DE Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) by imf27.hostedemail.com (Postfix) with ESMTP id 8C5D140033 for ; Wed, 31 Jul 2024 11:08:56 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="k/mhhyf4"; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.49 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=1722424132; 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=/Zk+cYfQy3/R+fSl4ijqOgCFd7jf0+0jsTHIqgoyTv8=; b=MPkzOaUxejFWylYwAkwll69YnWx/xdkv24D/2RhZA8+fCxGTJkJ0szYuEQA9MLOqArK7xI k63Cjw/YJqnPUO5/qw6hN8vWpg59SJtUpqts8qacka8hsfwE0HpkYNeHtWN6ezqoch4CKb Fn9ty9JAeG5xpVNGymcq8LvKUqPooyw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="k/mhhyf4"; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.49 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=1722424132; a=rsa-sha256; cv=none; b=KrEKMr+5VV0zJzxVzsP/AEIImy9ONxOYq0UhHLBWRhWfpHeTTNvivwwHOE3aQ4/byBh6rB h63F88+v0pF3CFZmejQGqi3SGVmHQtV9H0882GkG/lgn9R5OwP4YyWR3ge14FqMU6JTP8X a+g5e2fxizG7WA6KNDxtRpYWOM5iKSg= Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-821b8d887b8so1519735241.2 for ; Wed, 31 Jul 2024 04:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722424135; x=1723028935; 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=/Zk+cYfQy3/R+fSl4ijqOgCFd7jf0+0jsTHIqgoyTv8=; b=k/mhhyf4jJ0QZmsC+gZMYGpRRXEiLUZkdU7SyD2oUGHxGzQPRRSR4XP8FpaIu0VyPE oehYYCF74QOyXXltQAT0v0+lM0DvO3H8JNgHbfVsSQbMuxw8fIOVTzzTkiXwi0SpUIWw KfDhWVRueaTpl+RJyVaQg71pK6JORpyN9cxdbz8sVUQelUxkRWtoizuovvQy7BCVPcjN CLriZ0BFpsna9wgDIPhEkk1FooTIQqnOWv6l/CprBA9RbnIB5Acc90AtRMMzkhY/398/ iPxU7gRHfuSw9XKDmaK/KcNsk9+bvN4THNGQxxYIaYjsz6cw4Db/1k77xNRTVmekGq9+ UEJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722424135; x=1723028935; 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=/Zk+cYfQy3/R+fSl4ijqOgCFd7jf0+0jsTHIqgoyTv8=; b=t1RM3VormqNOV6np5Ir3qccvLQi/qHgp4MtqOAeZBTYGi52qdjsq+503I1kp0f8koH AaBW5fR3YNk/OG7i2J3rthZjYly7O7xj3CRIDcpxNCTZnHmQQiDj0/4yGxV7vkt+5aqc DAW40pxI67+NHb7mpwAgaS/Iqct/fcPupVbik6Dld6PHvMIKUnn+tyyCu+/hkkW7mAot E4aoDPMZ6fIzlWAORQyv3lTI1XqB49lTo8OUA5kqD5YU09d9/ajz2/GjwVhdOkEXA2of 7Dth/Fl5ckgBgTjzILLua3+J4zfJxYCUykeSO6c+pIzuC9WUTAVtZ6vbio4tIhx7qs+w RNsQ== X-Forwarded-Encrypted: i=1; AJvYcCX5GxkHTDT1PSOVNKns77ecnAXtWrQqLh3HIrcAXxRszpe4eml0fqfOucuDzwRpHrUFgiw0JaZblVb1g834lkgBiG4= X-Gm-Message-State: AOJu0YzSN7Uvvh5WjH28z+ZrYswOXb/fWWtSu/68scS/XmEmp34AXdiE 6hBelYO9kvWd9B/CW1NSE6gkO2Qzzpso9XmSRF69rKIxk22x2DuwQj2G/5NUZkO10uk21Cc/MLo C1XTSDnjbDtCA3W3a0YmMLh2BMw4= X-Google-Smtp-Source: AGHT+IFx//wnEVQXnfiGegpRRqukUM3xN1R0pbdxyTIOXbkqjXkzWbl45gqbN6xoDEdxHdqqxxslJLvapfxTJK9qfp0= X-Received: by 2002:a05:6122:210f:b0:4eb:39c9:c935 with SMTP id 71dfb90a1353d-4f6e6989ff8mr10127941e0c.14.1722424135422; Wed, 31 Jul 2024 04:08:55 -0700 (PDT) MIME-Version: 1.0 References: <20240731000155.109583-1-21cnbao@gmail.com> <20240731000155.109583-5-21cnbao@gmail.com> <19981556-cecd-4f58-8b3b-bc3bb85a6ac4@suse.cz> In-Reply-To: <19981556-cecd-4f58-8b3b-bc3bb85a6ac4@suse.cz> From: Barry Song <21cnbao@gmail.com> Date: Wed, 31 Jul 2024 19:08:44 +0800 Message-ID: Subject: Re: [PATCH v2 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Vlastimil Babka 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, virtualization@lists.linux.dev, Kees Cook , lorenzo.stoakes@oracle.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: y41o1xhgr91oj4rzayn6qjtdyxduimdw X-Rspamd-Queue-Id: 8C5D140033 X-Rspamd-Server: rspam11 X-HE-Tag: 1722424136-582717 X-HE-Meta: U2FsdGVkX1/slP7wHQjwFeljlCH1MV8o8s0BvsQSszFtbchQpQC5+rVm/wS79TBFIJYMYHe4guZ5OPlNHcJk3wo/MSB3zR3grfc9VjEgGPZWlH22LRLECP0fGra+40JvLUoai4KEX1qNwifqRJ134idoA37cwpkirRSuUMIh3v2IXnpJ8oQpRxYwVkqZKSGarA5hKsm77yFV3IrsZQB7Zw33IXioqefPdMCj2qiu9FS35Wp5SIfgxr1lbbNE5j3FMUrt4neqsa62I8K0d32OfzDSFh8PGC56jcC7wovlLYAmRgfDZIhkOLfHz/DPJCiioTRVa3/W/+gF51j7GgCW+EBMELGRRVgIvIqdro8nPunmMICXjESHiRbuDu1xJbgvW35H4Zpr0XpR/sZRJwa4vjYe2yta5rnXXwc3BuxB0PSPKiWCnEtNUMlkrYTv4rWD/vwIYuNqPfJKYzx++fzf7Mq7fniNM/x6vemyjeXmBINEI+5c4CrUwCIfVaUz/sFMH+ZoYK+z004ksXAyfOb4K2oPkEvonAcx1UJEP9ypoGhdyhuSSzgs0iU9IkNxEZMBEjTfeg1F2iLpCaOks3/n1z/QyFc8YY6UVx9ftmcShYydtiHUAqKHZoFgLHVUQpyBNncL3ethBZdAHg4z8sH63Yih9ehirtLyiSYrFVzlmYrVZQi4cGJBeXo/pAE91IyseMW+vgJvvwrW2NmaAcmU09NggRlDfYt+FgZ/37DEMcXnHO98PEHkZzvSQuSnpCAjA19/qtqpeLMM0r3ezCK9f3bwG6UNdUsMkUfxeXyCkxU0qS2xDWU8tRpLLEuMOA2/Qq31zFjv5GXJVkR0bw1Yb6XQjHUsJZE6InIwUgoAcpR5gOd3yCRck34XDtyJaWaXBioo0INy/hMoovK889GUtGhUL9Os0uIziJTZjh1s0fI/HeXWXz5aB+vUkInfvJZdoz4zXU0s66vbpkhxk1g Xt3pSzmi PfXy4FbuYzJ/laHrLxFKNOUXyQDlSdwSEj3GNLNJ3/XlgIOsUyo2hfDCMY/y0ikcYXa0+sknD+bpxcfje2Hsc4gY1748YKsFMKrYRQPcYfuSuqesomo2CkQrkvhh0Tr/3kB/MloHfs30qHtyuXtZBlAYDnbhV4qbbMFcDYUoSJi79qKd2b6SZB7WENMQ4NRAEeff1Do1zcbdkox8LnMYNc0Byt1DF85BGvoHcqBR4neXTqSg07baUQ3D4GjO8inERbbWHM4qH8kQzmAzfZmDF8MecMr63Tv6bIRphM6/V6gmI79q/BwriaVqTS3+nf7H6tkjogjKqOBZXDWTScJ2fc69WrXkCQpJPspRR8HNkjfR1FW/pGwTLXm+s01PwfhPd1FonuOxl7Ra1kjRxhBM9PnV87elqJ4v0xqWwqYJbmH0BFPfhOADumSj6y8xtshTQs5eiXu6pviMGvoIMlVKSsv/h3i5jk9EvS5lXaDOT3yNb2o+oXgJSUfN335bN9hkiIKXpf3dct56kiWm49ycgLwvg13VCPYXTXoSracFHrdqXJem065POTfPktJUMInnr10268nuGQfeQrbuZbv5M5QfFL4UI4/W8v2XpWhkLuMrq9Z5c5hYcEzYuX8g8pKzDa4bwf7LFoVfr2JinPrOyJgzpkdtsa3SndHLMf585GMB/hADsRNkfi2FTUKwImoyntRUJ/SOw2W06brrfiXGBraf996jj02pXjVFlnDNn7nZqrD3ZQAYkIAiHofKUog+vzDWTubb/BYy2T3Rrgyc4UODR7u4CR6ol7/F5jhJRFdP4ZhZGthxjiN1h2Mgn2ilEmid5E+j2v8F5HdQgSK9++hyHtUYTA0Gut6oPkHZOYR1fR/CH2TJPT2nsVQ== 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, Jul 31, 2024 at 6:55=E2=80=AFPM Vlastimil Babka wr= ote: > > 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 o= r > > 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. E= ven > > if the process incorrectly using __GFP_NOFAIL is sometimes rescued, the > > long latency might be unacceptable, especially considering that misusin= g > > 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 pag= e > > + * 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 situatio= n > so it would be wrong. If we use BUG_ON, it seems like we don't need to do anything else, as the B= UG_ON report gives developers all the information they need. If we go with approach 1=E2=80=94doing a busy loop until rescued or a lockup occurs=E2=80=94I agree it might be better to add more warnings. > > > > > /* > > * PF_MEMALLOC request from this context is rather bizarr= e > > @@ -4474,7 +4474,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: >