* [PATCH] fs: use kvmalloc for big coredump file
@ 2022-08-30 6:55 zhaoyang.huang
2022-09-18 2:29 ` Zhaoyang Huang
0 siblings, 1 reply; 5+ messages in thread
From: zhaoyang.huang @ 2022-08-30 6:55 UTC (permalink / raw)
To: Alexander Viro, Zhaoyang Huang, linux-kernel, ke.wang
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
High order page allocation observed which even introduce kernel panic when generating
coredump file, use kvmalloc_array instead of kmalloc_array
[68058.982108] init: Untracked pid 3847 exited with status 0
[68058.982343] init: Untracked pid 3847 did not have an associated service entry and will not be reaped
[68059.038127] warn_alloc: 29 callbacks suppressed
[68059.038132] TimerThread: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=foreground,mems_allowed=0
[68059.038155] CPU: 6 PID: 3597 Comm: TimerThread Tainted: G W OE 5.15.41-android13-8-01198-g03458ee9a090-ab000039 #1
[68059.038159] Hardware name: Unisoc UMS9620-base Board (DT)
[68059.038161] Call trace:
[68059.038163] dump_backtrace.cfi_jt+0x0/0x8
[68059.038169] dump_stack_lvl+0x98/0xe8
[68059.038174] warn_alloc+0x164/0x200
[68059.038180] __alloc_pages_slowpath+0x9d4/0xb64
[68059.038183] __alloc_pages+0x21c/0x39c
[68059.038186] kmalloc_order+0x4c/0x13c
[68059.038189] kmalloc_order_trace+0x34/0x154
[68059.038192] __kmalloc+0x600/0x8a8
[68059.038196] elf_core_dump+0x7c4/0x15d8
[68059.038201] do_coredump+0x680/0xe54
[68059.038203] get_signal+0x610/0x988
[68059.038209] do_signal+0xd4/0x2bc
[68059.038213] do_notify_resume+0xa0/0x1c8
[68059.038216] el0_svc+0x68/0x90
[68059.038219] el0t_64_sync_handler+0x88/0xec
[68059.038222] el0t_64_sync+0x1b4/0x1b8
Reported-by: Guanglu Xu <guanglu.xu@unisoc.com>
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
fs/coredump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index ebc43f9..ed9b191 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -213,7 +213,7 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm,
if (ispipe) {
int argvs = sizeof(core_pattern) / 2;
- (*argv) = kmalloc_array(argvs, sizeof(**argv), GFP_KERNEL);
+ (*argv) = kvmalloc_array(argvs, sizeof(**argv), GFP_KERNEL);
if (!(*argv))
return -ENOMEM;
(*argv)[(*argc)++] = 0;
@@ -612,7 +612,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
goto fail_dropcount;
}
- helper_argv = kmalloc_array(argc + 1, sizeof(*helper_argv),
+ helper_argv = kvmalloc_array(argc + 1, sizeof(*helper_argv),
GFP_KERNEL);
if (!helper_argv) {
printk(KERN_WARNING "%s failed to allocate memory\n",
--
1.9.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] fs: use kvmalloc for big coredump file
2022-08-30 6:55 [PATCH] fs: use kvmalloc for big coredump file zhaoyang.huang
@ 2022-09-18 2:29 ` Zhaoyang Huang
2022-09-18 2:42 ` Al Viro
0 siblings, 1 reply; 5+ messages in thread
From: Zhaoyang Huang @ 2022-09-18 2:29 UTC (permalink / raw)
To: zhaoyang.huang, Eric W. Biederman; +Cc: Alexander Viro, LKML, Ke Wang
loop Eric W
On Tue, Aug 30, 2022 at 2:56 PM zhaoyang.huang
<zhaoyang.huang@unisoc.com> wrote:
>
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> High order page allocation observed which even introduce kernel panic when generating
> coredump file, use kvmalloc_array instead of kmalloc_array
>
> [68058.982108] init: Untracked pid 3847 exited with status 0
> [68058.982343] init: Untracked pid 3847 did not have an associated service entry and will not be reaped
> [68059.038127] warn_alloc: 29 callbacks suppressed
> [68059.038132] TimerThread: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=foreground,mems_allowed=0
> [68059.038155] CPU: 6 PID: 3597 Comm: TimerThread Tainted: G W OE 5.15.41-android13-8-01198-g03458ee9a090-ab000039 #1
> [68059.038159] Hardware name: Unisoc UMS9620-base Board (DT)
> [68059.038161] Call trace:
> [68059.038163] dump_backtrace.cfi_jt+0x0/0x8
> [68059.038169] dump_stack_lvl+0x98/0xe8
> [68059.038174] warn_alloc+0x164/0x200
> [68059.038180] __alloc_pages_slowpath+0x9d4/0xb64
> [68059.038183] __alloc_pages+0x21c/0x39c
> [68059.038186] kmalloc_order+0x4c/0x13c
> [68059.038189] kmalloc_order_trace+0x34/0x154
> [68059.038192] __kmalloc+0x600/0x8a8
> [68059.038196] elf_core_dump+0x7c4/0x15d8
> [68059.038201] do_coredump+0x680/0xe54
> [68059.038203] get_signal+0x610/0x988
> [68059.038209] do_signal+0xd4/0x2bc
> [68059.038213] do_notify_resume+0xa0/0x1c8
> [68059.038216] el0_svc+0x68/0x90
> [68059.038219] el0t_64_sync_handler+0x88/0xec
> [68059.038222] el0t_64_sync+0x1b4/0x1b8
>
> Reported-by: Guanglu Xu <guanglu.xu@unisoc.com>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
> fs/coredump.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/coredump.c b/fs/coredump.c
> index ebc43f9..ed9b191 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -213,7 +213,7 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm,
>
> if (ispipe) {
> int argvs = sizeof(core_pattern) / 2;
> - (*argv) = kmalloc_array(argvs, sizeof(**argv), GFP_KERNEL);
> + (*argv) = kvmalloc_array(argvs, sizeof(**argv), GFP_KERNEL);
> if (!(*argv))
> return -ENOMEM;
> (*argv)[(*argc)++] = 0;
> @@ -612,7 +612,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
> goto fail_dropcount;
> }
>
> - helper_argv = kmalloc_array(argc + 1, sizeof(*helper_argv),
> + helper_argv = kvmalloc_array(argc + 1, sizeof(*helper_argv),
> GFP_KERNEL);
> if (!helper_argv) {
> printk(KERN_WARNING "%s failed to allocate memory\n",
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fs: use kvmalloc for big coredump file
2022-09-18 2:29 ` Zhaoyang Huang
@ 2022-09-18 2:42 ` Al Viro
2022-09-18 21:55 ` Eric W. Biederman
0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2022-09-18 2:42 UTC (permalink / raw)
To: Zhaoyang Huang; +Cc: zhaoyang.huang, Eric W. Biederman, LKML, Ke Wang
On Sun, Sep 18, 2022 at 10:29:10AM +0800, Zhaoyang Huang wrote:
> loop Eric W
>
> On Tue, Aug 30, 2022 at 2:56 PM zhaoyang.huang
> <zhaoyang.huang@unisoc.com> wrote:
> >
> > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >
> > High order page allocation observed which even introduce kernel panic when generating
> > coredump file, use kvmalloc_array instead of kmalloc_array
Frankly, I would rather cap argc here - if you are trying to feed that many arguments
to your userland helper, your core_pattern is probably bogus.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fs: use kvmalloc for big coredump file
2022-09-18 2:42 ` Al Viro
@ 2022-09-18 21:55 ` Eric W. Biederman
0 siblings, 0 replies; 5+ messages in thread
From: Eric W. Biederman @ 2022-09-18 21:55 UTC (permalink / raw)
To: Al Viro; +Cc: Zhaoyang Huang, zhaoyang.huang, LKML, Ke Wang, Oleg Nesterov
Adding Oleg as well.
Al Viro <viro@zeniv.linux.org.uk> writes:
> On Sun, Sep 18, 2022 at 10:29:10AM +0800, Zhaoyang Huang wrote:
>> loop Eric W
>>
>> On Tue, Aug 30, 2022 at 2:56 PM zhaoyang.huang
>> <zhaoyang.huang@unisoc.com> wrote:
>> >
>> > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>> >
>> > High order page allocation observed which even introduce kernel panic when generating
>> > coredump file, use kvmalloc_array instead of kmalloc_array
>
> Frankly, I would rather cap argc here - if you are trying to feed that many arguments
> to your userland helper, your core_pattern is probably bogus.
Yes. More than 512 arguments seems ridiculous. I only count
16 different values that can be place in corename so frankly a cap
of about 20 seems sensible.
I would suggest counting the number of spaces in core pattern and not
allowing it to be set if the result would be more than
"PAGE_SIZE/sizeof(void *)" arguments.
I would reduce that by one more argument so that helper_argv is
completely unnecessary. Unless I am misreading something the
only reason for helper_argv is to add a NULL at the end of
the argv array. It should be no problem to have format_corename
do that work as well.
If you have a real world case where that is a problem please post
the useful corepattern so that we can stare in disbelief and finally
come around to figuring out how to support such a core pattern.
Thank you,
Eric
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] fs: use kvmalloc for big coredump file
@ 2022-09-01 1:18 zhaoyang.huang
0 siblings, 0 replies; 5+ messages in thread
From: zhaoyang.huang @ 2022-09-01 1:18 UTC (permalink / raw)
To: Alexander Viro, Zhaoyang Huang, linux-kernel, ke.wang
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
High order page allocation observed which even introduce kernel panic when generating
coredump file, use kvmalloc_array instead of kmalloc_array
[68058.982108] init: Untracked pid 3847 exited with status 0
[68058.982343] init: Untracked pid 3847 did not have an associated service entry and will not be reaped
[68059.038127] warn_alloc: 29 callbacks suppressed
[68059.038132] TimerThread: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=foreground,mems_allowed=0
[68059.038155] CPU: 6 PID: 3597 Comm: TimerThread Tainted: G W OE 5.15.41-android13-8-01198-g03458ee9a090-ab000039 #1
[68059.038159] Hardware name: Unisoc UMS9620-base Board (DT)
[68059.038161] Call trace:
[68059.038163] dump_backtrace.cfi_jt+0x0/0x8
[68059.038169] dump_stack_lvl+0x98/0xe8
[68059.038174] warn_alloc+0x164/0x200
[68059.038180] __alloc_pages_slowpath+0x9d4/0xb64
[68059.038183] __alloc_pages+0x21c/0x39c
[68059.038186] kmalloc_order+0x4c/0x13c
[68059.038189] kmalloc_order_trace+0x34/0x154
[68059.038192] __kmalloc+0x600/0x8a8
[68059.038196] elf_core_dump+0x7c4/0x15d8
[68059.038201] do_coredump+0x680/0xe54
[68059.038203] get_signal+0x610/0x988
[68059.038209] do_signal+0xd4/0x2bc
[68059.038213] do_notify_resume+0xa0/0x1c8
[68059.038216] el0_svc+0x68/0x90
[68059.038219] el0t_64_sync_handler+0x88/0xec
[68059.038222] el0t_64_sync+0x1b4/0x1b8
Reported-by: Guanglu Xu <guanglu.xu@unisoc.com>
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
fs/coredump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index ebc43f9..52e9177 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -612,7 +612,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
goto fail_dropcount;
}
- helper_argv = kmalloc_array(argc + 1, sizeof(*helper_argv),
+ helper_argv = kvmalloc_array(argc + 1, sizeof(*helper_argv),
GFP_KERNEL);
if (!helper_argv) {
printk(KERN_WARNING "%s failed to allocate memory\n",
@@ -631,7 +631,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
retval = call_usermodehelper_exec(sub_info,
UMH_WAIT_EXEC);
- kfree(helper_argv);
+ kvfree(helper_argv);
if (retval) {
printk(KERN_INFO "Core dump to |%s pipe failed\n",
cn.corename);
--
1.9.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-09-18 21:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-30 6:55 [PATCH] fs: use kvmalloc for big coredump file zhaoyang.huang
2022-09-18 2:29 ` Zhaoyang Huang
2022-09-18 2:42 ` Al Viro
2022-09-18 21:55 ` Eric W. Biederman
2022-09-01 1:18 zhaoyang.huang
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.