From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Young <dyoung@redhat.com>
Cc: Baoquan He <bhe@redhat.com>, Xunlei Pang <xlpang@redhat.com>,
Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>,
Petr Tesarik <ptesarik@suse.cz>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
kexec@lists.infradead.org
Subject: Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section
Date: Tue, 21 Mar 2017 22:18:30 -0500 [thread overview]
Message-ID: <87pohaxam1.fsf@xmission.com> (raw)
In-Reply-To: <20170322025536.GA4424@dhcp-128-65.nay.redhat.com> (Dave Young's message of "Wed, 22 Mar 2017 10:55:36 +0800")
Dave Young <dyoung@redhat.com> writes:
> On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
>> Xunlei Pang <xlpang@redhat.com> writes:
>>
>> > As Eric said,
>> > "what we need to do is move the variable vmcoreinfo_note out
>> > of the kernel's .bss section. And modify the code to regenerate
>> > and keep this information in something like the control page.
>> >
>> > Definitely something like this needs a page all to itself, and ideally
>> > far away from any other kernel data structures. I clearly was not
>> > watching closely the data someone decided to keep this silly thing
>> > in the kernel's .bss section."
>> >
>> > This patch allocates extra pages for these vmcoreinfo_XXX variables,
>> > one advantage is that it enhances some safety of vmcoreinfo, because
>> > vmcoreinfo now is kept far away from other kernel data structures.
>>
>> Can you preceed this patch with a patch that removes CRASHTIME from
>> vmcoreinfo? If someone actually cares we can add a separate note that holds
>> a 64bit crashtime in the per cpu notes.
>
> I think makedumpfile is using it, but I also vote to remove the
> CRASHTIME. It is better not to do this while crashing and a makedumpfile
> userspace patch is needed to drop the use of it.
>
>>
>> As we are looking at reliability concerns removing CRASHTIME should make
>> everything in vmcoreinfo a boot time constant. Which should simplify
>> everything considerably.
>
> It is a nice improvement..
We also need to take a close look at what s390 is doing with vmcoreinfo.
As apparently it is reading it in a different kind of crashdump process.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Young <dyoung@redhat.com>
Cc: Xunlei Pang <xlpang@redhat.com>, Baoquan He <bhe@redhat.com>,
Petr Tesarik <ptesarik@suse.cz>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org,
Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>
Subject: Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section
Date: Tue, 21 Mar 2017 22:18:30 -0500 [thread overview]
Message-ID: <87pohaxam1.fsf@xmission.com> (raw)
In-Reply-To: <20170322025536.GA4424@dhcp-128-65.nay.redhat.com> (Dave Young's message of "Wed, 22 Mar 2017 10:55:36 +0800")
Dave Young <dyoung@redhat.com> writes:
> On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
>> Xunlei Pang <xlpang@redhat.com> writes:
>>
>> > As Eric said,
>> > "what we need to do is move the variable vmcoreinfo_note out
>> > of the kernel's .bss section. And modify the code to regenerate
>> > and keep this information in something like the control page.
>> >
>> > Definitely something like this needs a page all to itself, and ideally
>> > far away from any other kernel data structures. I clearly was not
>> > watching closely the data someone decided to keep this silly thing
>> > in the kernel's .bss section."
>> >
>> > This patch allocates extra pages for these vmcoreinfo_XXX variables,
>> > one advantage is that it enhances some safety of vmcoreinfo, because
>> > vmcoreinfo now is kept far away from other kernel data structures.
>>
>> Can you preceed this patch with a patch that removes CRASHTIME from
>> vmcoreinfo? If someone actually cares we can add a separate note that holds
>> a 64bit crashtime in the per cpu notes.
>
> I think makedumpfile is using it, but I also vote to remove the
> CRASHTIME. It is better not to do this while crashing and a makedumpfile
> userspace patch is needed to drop the use of it.
>
>>
>> As we are looking at reliability concerns removing CRASHTIME should make
>> everything in vmcoreinfo a boot time constant. Which should simplify
>> everything considerably.
>
> It is a nice improvement..
We also need to take a close look at what s390 is doing with vmcoreinfo.
As apparently it is reading it in a different kind of crashdump process.
Eric
next prev parent reply other threads:[~2017-03-22 3:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-20 5:50 [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section Xunlei Pang
2017-03-20 5:50 ` Xunlei Pang
2017-03-20 5:50 ` [PATCH v3 2/3] powerpc/fadump: Use the correct VMCOREINFO_NOTE_SIZE for phdr Xunlei Pang
2017-03-20 5:50 ` Xunlei Pang
2017-03-20 5:50 ` [PATCH v3 3/3] kdump: Relocate vmcoreinfo to the crash memory range Xunlei Pang
2017-03-20 5:50 ` Xunlei Pang
2017-03-21 3:33 ` [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section Eric W. Biederman
2017-03-21 3:33 ` Eric W. Biederman
2017-03-22 2:55 ` Dave Young
2017-03-22 2:55 ` Dave Young
2017-03-22 3:18 ` Eric W. Biederman [this message]
2017-03-22 3:18 ` Eric W. Biederman
2017-03-22 4:30 ` Dave Young
2017-03-22 4:30 ` Dave Young
2017-03-22 9:34 ` Xunlei Pang
2017-03-22 9:34 ` Xunlei Pang
2017-03-22 12:15 ` Hari Bathini
2017-03-22 12:15 ` Hari Bathini
2017-03-22 11:46 ` Hari Bathini
2017-03-22 11:46 ` Hari Bathini
2017-03-22 20:48 ` Michael Holzheu
2017-03-22 20:48 ` Michael Holzheu
2017-03-23 9:23 ` Xunlei Pang
2017-03-23 9:23 ` Xunlei Pang
2017-03-23 17:46 ` Michael Holzheu
2017-03-23 17:46 ` Michael Holzheu
2017-03-24 11:03 ` Xunlei Pang
2017-03-24 11:03 ` Xunlei Pang
2017-03-22 8:55 ` Xunlei Pang
2017-03-22 8:55 ` Xunlei Pang
2017-03-22 9:16 ` Xunlei Pang
2017-03-22 9:16 ` Xunlei Pang
2017-03-22 9:17 ` Xunlei Pang
2017-03-22 9:17 ` Xunlei Pang
2017-03-21 9:27 ` Petr Tesarik
2017-03-21 9:27 ` Petr Tesarik
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=87pohaxam1.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=ats-kumagai@wm.jp.nec.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptesarik@suse.cz \
--cc=xlpang@redhat.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.