From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
LKML <linux-kernel@vger.kernel.org>, Ke Wang <ke.wang@unisoc.com>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH] fs: use kvmalloc for big coredump file
Date: Sun, 18 Sep 2022 16:55:17 -0500 [thread overview]
Message-ID: <87wna073ga.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <YyaFrarLHYW3HSnu@ZenIV> (Al Viro's message of "Sun, 18 Sep 2022 03:42:53 +0100")
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
next prev parent reply other threads:[~2022-09-18 21:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-09-01 1:18 zhaoyang.huang
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=87wna073ga.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=huangzhaoyang@gmail.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zhaoyang.huang@unisoc.com \
/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.