From: Douglas Anderson <dianders@chromium.org>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>
Cc: Douglas Anderson <dianders@chromium.org>,
Eric Biederman <ebiederm@xmission.com>, Jan Kara <jack@suse.cz>,
Kees Cook <keescook@chromium.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: [PATCH] regset: use vmalloc() for regset_get_alloc()
Date: Thu, 1 Feb 2024 17:12:03 -0800 [thread overview]
Message-ID: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> (raw)
While browsing through ChromeOS crash reports, I found one with an
allocation failure that looked like this:
chrome: page allocation failure: order:7,
mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
nodemask=(null),cpuset=urgent,mems_allowed=0
CPU: 7 PID: 3295 Comm: chrome Not tainted
5.15.133-20574-g8044615ac35c #1 (HASH:1162 1)
Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT)
Call trace:
dump_backtrace+0x0/0x1ec
show_stack+0x20/0x2c
dump_stack_lvl+0x60/0x78
dump_stack+0x18/0x38
warn_alloc+0x104/0x174
__alloc_pages+0x5f0/0x6e4
kmalloc_order+0x44/0x98
kmalloc_order_trace+0x34/0x124
__kmalloc+0x228/0x36c
__regset_get+0x68/0xcc
regset_get_alloc+0x1c/0x28
elf_core_dump+0x3d8/0xd8c
do_coredump+0xeb8/0x1378
get_signal+0x14c/0x804
...
An order 7 allocation is (1 << 7) contiguous pages, or 512K. It's not
a surprise that this allocation failed on a system that's been running
for a while.
In this case we're just generating a core dump and there's no reason
we need contiguous memory. Change the allocation to vmalloc(). We'll
change the free in binfmt_elf to kvfree() which works regardless of
how the memory was allocated.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
I don't know this code at all, but I _think_ I've identified the
places where the memory is freed correctly. Please double-check that I
didn't miss anything obvious, though!
fs/binfmt_elf.c | 2 +-
kernel/regset.c | 7 ++++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 5397b552fbeb..ac178ad38823 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1928,7 +1928,7 @@ static void free_note_info(struct elf_note_info *info)
threads = t->next;
WARN_ON(t->notes[0].data && t->notes[0].data != &t->prstatus);
for (i = 1; i < info->thread_notes; ++i)
- kfree(t->notes[i].data);
+ kvfree(t->notes[i].data);
kfree(t);
}
kfree(info->psinfo.data);
diff --git a/kernel/regset.c b/kernel/regset.c
index 586823786f39..ed8d8cf3a22c 100644
--- a/kernel/regset.c
+++ b/kernel/regset.c
@@ -2,6 +2,7 @@
#include <linux/export.h>
#include <linux/slab.h>
#include <linux/regset.h>
+#include <linux/vmalloc.h>
static int __regset_get(struct task_struct *target,
const struct user_regset *regset,
@@ -16,14 +17,14 @@ static int __regset_get(struct task_struct *target,
if (size > regset->n * regset->size)
size = regset->n * regset->size;
if (!p) {
- to_free = p = kzalloc(size, GFP_KERNEL);
+ to_free = p = vmalloc(size);
if (!p)
return -ENOMEM;
}
res = regset->regset_get(target, regset,
(struct membuf){.p = p, .left = size});
if (res < 0) {
- kfree(to_free);
+ vfree(to_free);
return res;
}
*data = p;
@@ -71,6 +72,6 @@ int copy_regset_to_user(struct task_struct *target,
ret = regset_get_alloc(target, regset, size, &buf);
if (ret > 0)
ret = copy_to_user(data, buf, ret) ? -EFAULT : 0;
- kfree(buf);
+ vfree(buf);
return ret;
}
--
2.43.0.594.gd9cf4e227d-goog
next reply other threads:[~2024-02-02 1:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 1:12 Douglas Anderson [this message]
2024-02-02 1:22 ` [PATCH] regset: use vmalloc() for regset_get_alloc() Al Viro
2024-02-02 2:54 ` Doug Anderson
2024-02-02 3:04 ` Al Viro
2024-02-02 3:15 ` Doug Anderson
2024-02-02 3:49 ` Al Viro
2024-02-02 4:05 ` Al Viro
2024-02-02 16:24 ` Doug Anderson
2024-02-02 16:24 ` Doug Anderson
2024-02-02 16:49 ` Al Viro
2024-02-02 16:49 ` Al Viro
2024-02-02 16:55 ` Al Viro
2024-02-02 16:55 ` Al Viro
2024-02-02 18:07 ` Dave Martin
2024-02-02 18:07 ` Dave Martin
2024-02-02 19:13 ` Doug Anderson
2024-02-02 19:13 ` Doug Anderson
2024-02-02 19:42 ` Mark Brown
2024-02-02 19:42 ` Mark Brown
2024-02-02 20:38 ` Doug Anderson
2024-02-02 20:38 ` Doug Anderson
2024-02-02 17:48 ` Mark Brown
2024-02-02 1:24 ` Matthew Wilcox
2024-02-02 2:58 ` Doug Anderson
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid \
--to=dianders@chromium.org \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.