The patch titled
Subject: mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags
has been added to the -mm tree. Its filename is
mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch
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 and is updated
there every 3-4 working days
------------------------------------------------------
From: Michal Hocko <mhocko@xxxxxxxx>
Subject: mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags
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)
kvmalloc
else
kmalloc
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.
Link: http://lkml.kernel.org/r/20180601115329.27807-1-mhocko@xxxxxxxxxx
Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
Suggested-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Tom Herbert <tom@xxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
lib/bucket_locks.c | 5 +----
mm/util.c | 6 ++++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff -puN lib/bucket_locks.c~mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags lib/bucket_locks.c
--- a/lib/bucket_locks.c~mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags
+++ a/lib/bucket_locks.c
@@ -30,10 +30,7 @@ int alloc_bucket_spinlocks(spinlock_t **
}
if (sizeof(spinlock_t) != 0) {
- if (gfpflags_allow_blocking(gfp))
- tlocks = kvmalloc(size * sizeof(spinlock_t), gfp);
- else
- tlocks = kmalloc_array(size, sizeof(spinlock_t), gfp);
+ tlocks = kvmalloc_array(size, sizeof(spinlock_t), gfp);
if (!tlocks)
return -ENOMEM;
for (i = 0; i < size; i++)
diff -puN mm/util.c~mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags mm/util.c
--- a/mm/util.c~mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags
+++ a/mm/util.c
@@ -391,7 +391,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)
{
@@ -402,7 +403,8 @@ void *kvmalloc_node(size_t size, gfp_t f
* vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
* so the given set of flags has to be compatible.
*/
- WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+ if ((flags & GFP_KERNEL) != GFP_KERNEL)
+ return kmalloc_node(size, flags, node);
/*
* We want to attempt a large physically contiguous block first because
_
Patches currently in -mm which might be from mhocko@xxxxxxxx are
mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
