archive mirror
 help / color / mirror / Atom feed
From: Rishabh Bhatnagar <>
To: <>, <>
Cc: <>, <>,
	<>, Michal Hocko <>,
	Linus Torvalds <>,
	Tom Herbert <>,
	"Andrew Morton" <>,
	Rishabh Bhatnagar <>
Subject: [PATCH stable 4.14 1/1] mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags
Date: Tue, 31 Jan 2023 04:38:15 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: Michal Hocko <>

Commit ce91f6ee5b3bbbad8caff61b1c46d845c8db19bf upstream.

kvmalloc warned about incompatible gfp_mask to catch abusers (mostly
GFP_NOFS) with an intention that this will motivate authors of the code
to fix those.  Linus argues that this just motivates people to do even
more hacks like

	if (gfp == GFP_KERNEL)

I haven't seen this happening much (Linus pointed to bucket_lock special
cases an atomic allocation but my git foo hasn't found much more) but it
is true that we can grow those in future.  Therefore Linus suggested to
simply not fallback to vmalloc for incompatible gfp flags and rather
stick with the kmalloc path.

Signed-off-by: Michal Hocko <>
Suggested-by: Linus Torvalds <>
Cc: Tom Herbert <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Rishabh Bhatnagar <>
- Removed lib/bucket_locks.c diff as not present in 4.14

 mm/util.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/util.c b/mm/util.c
index 84e775f5216f..7d80c8119dce 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -400,7 +400,8 @@ EXPORT_SYMBOL(vm_mmap);
  * __GFP_RETRY_MAYFAIL is supported, and it should be used only if kmalloc is
  * preferable to the vmalloc fallback, due to visible performance drawbacks.
- * Any use of gfp flags outside of GFP_KERNEL should be consulted with mm people.
+ * Please note that any use of gfp flags outside of GFP_KERNEL is careful to not
+ * fall back to vmalloc.
 void *kvmalloc_node(size_t size, gfp_t flags, int node)
@@ -411,7 +412,8 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
 	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
 	 * so the given set of flags has to be compatible.
+	if ((flags & GFP_KERNEL) != GFP_KERNEL)
+		return kmalloc_node(size, flags, node);
 	 * We want to attempt a large physically contiguous block first because

  reply	other threads:[~2023-01-31  4:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31  4:38 [PATCH stable 4.14 0/1] Fix ext4 xfstests failure Rishabh Bhatnagar
2023-01-31  4:38 ` Rishabh Bhatnagar [this message]
2023-02-03  8:00 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).