The patch titled
Subject: mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL
has been added to the -mm mm-unstable branch. Its filename is
mm-prohibit-null-deference-exposed-for-unsupported-non-blockable-__gfp_nofail.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-prohibit-null-deference-exposed-for-unsupported-non-blockable-__gfp_nofail.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Barry Song <v-songbaohua@xxxxxxxx>
Subject: mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL
Date: Wed, 31 Jul 2024 12:01:55 +1200
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.
Link: https://lkml.kernel.org/r/20240731000155.109583-5-21cnbao@xxxxxxxxx
Signed-off-by: Barry Song <v-songbaohua@xxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx>
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Cc: Lorenzo Stoakes <lstoakes@xxxxxxxxx>
Cc: Christoph Lameter <cl@xxxxxxxxx>
Cc: Pekka Enberg <penberg@xxxxxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Cc: Roman Gushchin <roman.gushchin@xxxxxxxxx>
Cc: Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Kees Cook <kees@xxxxxxxxxx>
Cc: "Eugenio Pérez" <eperezma@xxxxxxxxxx>
Cc: Hailong.Liu <hailong.liu@xxxxxxxx>
Cc: Jason Wang <jasowang@xxxxxxxxxx>
Cc: Maxime Coquelin <maxime.coquelin@xxxxxxxxxx>
Cc: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
Cc: Xuan Zhuo <xuanzhuo@xxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/page_alloc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/mm/page_alloc.c~mm-prohibit-null-deference-exposed-for-unsupported-non-blockable-__gfp_nofail
+++ a/mm/page_alloc.c
@@ -4404,11 +4404,11 @@ nopage:
*/
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);
/*
* PF_MEMALLOC request from this context is rather bizarre
@@ -4439,7 +4439,7 @@ nopage:
cond_resched();
goto retry;
}
-fail:
+
warn_alloc(gfp_mask, ac->nodemask,
"page allocation failure: order:%u", order);
got_pg:
_
Patches currently in -mm which might be from v-songbaohua@xxxxxxxx are
mm-extend-usage-parameter-so-that-cluster_swap_free_nr-can-be-reused.patch
mm-swap-add-nr-argument-in-swapcache_prepare-and-swapcache_clear-to-support-large-folios.patch
vpda-try-to-fix-the-potential-crash-due-to-misusing-__gfp_nofail.patch
mm-document-__gfp_nofail-must-be-blockable.patch
mm-bug_on-to-avoid-null-deference-while-__gfp_nofail-fails.patch
mm-prohibit-null-deference-exposed-for-unsupported-non-blockable-__gfp_nofail.patch
