From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Anderson <anderson@redhat.com>
Cc: Haren Myneni <hbabu@us.ibm.com>,
Morton Andrew Morton <akpm@osdl.org>,
Fastboot mailing list <fastboot@lists.osdl.org>,
fastboot-bounces@lists.osdl.org,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernelcore dumps
Date: Fri, 23 Sep 2005 01:12:23 -0600 [thread overview]
Message-ID: <m1ll1ob6lk.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <4332FD56.2F5256F5@redhat.com> (Dave Anderson's message of "Thu, 22 Sep 2005 14:52:06 -0400")
Dave Anderson <anderson@redhat.com> writes:
> So does elf_core_dump() as well, but to gdb it's useless AFAICT...
We can always post_process things when generating a core dump
if we have enough information.
> Hey -- I wasn't even aware of the "crashing_cpu" variable.
> That would work just fine.
>
> Still a "panic_task", and perhaps even a "crash_page_size" variable
> would be nice as well. No additional notes required...
To avoid defining an ABI that we need to maintain there is some
benefit in simply using static variables. But the form of the
information really isn't the concern.
Where we capture the information and how reliable is that capture
is the concern.
To capture page size the easiest and most reliable way I can see
to do is to modify vmlinux.lds.S to contain something like:
> _page_shift = PAGE_SHIFT;
Giving you an absolute symbol _page_shift in vmlinux that
contains the value you need, without overhead in the running
kernel.
crashing_cpu makes sense to capture in some form, we definitely
need to compute something that will allow us to write to
a per cpu area on an SMP system.
The big concern at this point is that the code has not undergone
a serious stability audit. So it is the expectation that there
is still code we can remove and modify to increase the likely hood
of getting a crash dump.
Currently we know that stack overflows sometimes happen and that
they are a source of kernel crashes. It would be good if we could
take a crash dump despite them. To do that requires code more
robust than we have today. Quite likely it means that we will
not be able to reliably capture the task_struct of the crashing cpu.
Eric
next prev parent reply other threads:[~2005-09-23 7:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 6:56 [PATCH] Kdump(x86): add note type NT_KDUMPINFO to kernel core dumps Vivek Goyal
2005-09-21 14:28 ` [Fastboot] " Eric W. Biederman
2005-09-21 15:17 ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernel " Dave Anderson
2005-09-22 9:01 ` Eric W. Biederman
2005-09-22 14:08 ` Vivek Goyal
2005-09-22 15:06 ` Dave Anderson
2005-09-22 16:31 ` Eric W. Biederman
2005-09-22 20:33 ` Haren Myneni
2005-09-23 5:09 ` Vivek Goyal
2005-09-23 7:22 ` Eric W. Biederman
2005-09-23 15:17 ` Subject: [PATCH] Don't uselessly export task_struct to user space in " Eric W. Biederman
[not found] ` <OF0A1E6B6F.F00DC760-ON87257084.005F99D6-88257084.00634A38@us.ibm.com>
2005-09-23 5:19 ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernel " Vivek Goyal
[not found] ` <4332FD56.2F5256F5@redhat.com>
2005-09-23 7:12 ` Eric W. Biederman [this message]
2005-09-23 12:01 ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernelcore dumps Vivek Goyal
2005-09-26 6:29 ` Vivek Goyal
2005-09-22 16:38 ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernel core dumps Eric W. Biederman
2005-09-22 17:00 ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFOtokernel " Dave Anderson
2005-09-22 7:39 ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO to kernel " Vivek Goyal
2005-09-22 7:46 ` Andrew Morton
2005-09-22 8:32 ` Vivek Goyal
2005-09-22 9:11 ` Eric W. Biederman
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=m1ll1ob6lk.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=anderson@redhat.com \
--cc=fastboot-bounces@lists.osdl.org \
--cc=fastboot@lists.osdl.org \
--cc=hbabu@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome