[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87wna073ga.fsf@email.froward.int.ebiederm.org>
Date: Sun, 18 Sep 2022 16:55:17 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Zhaoyang Huang <huangzhaoyang@...il.com>,
"zhaoyang.huang" <zhaoyang.huang@...soc.com>,
LKML <linux-kernel@...r.kernel.org>,
Ke Wang <ke.wang@...soc.com>, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH] fs: use kvmalloc for big coredump file
Adding Oleg as well.
Al Viro <viro@...iv.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@...soc.com> wrote:
>> >
>> > From: Zhaoyang Huang <zhaoyang.huang@...soc.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
Powered by blists - more mailing lists