|| ||"Eric W. Biederman" <email@example.com>|
|| ||Andrew Morton <firstname.lastname@example.org>|
|| ||[PATCH 0/29] overview|
|| ||Wed, 19 Jan 2005 0:31:37 -0700|
|| ||<email@example.com>, <firstname.lastname@example.org>|
Andrew the following patchset is against 2.6.11-rc1-mm1 with
all of the kexec patches removed. The list of removed patches
is included below.
This patchsset is a major refresh of the kexec on panic
functionality in the kernel. The primary aim of which was to take
the requirements capture of the kernel crashdump patches and
start integrating the functionality cleanly into the kexec
- Compat syscall support has been added.
- The crashdump capture code has been separated from the kexec on panic code.
- The kernel to jump to on panic is now loaded in place.
- A long standing bug that allowed 2 sources pages to copy data
to a single destination page has been caught and fixed.
- Support for loading an x86_64 kernel in a reserved of memory has been
The crashdump code is currently slightly broken. I have attempted to
minimize the breakage so things can quick be made to work again.
With respect to a final design discussion there are two remaining
open issues. The first is how little hardware shutdown we can get away
with in the kernel that is panicing. I believe we can reduce this
to a simply NMI to the other cpus telling them to stop. This has
been address as a major concern in previous conversations.
The second is an issue is the most significant with respect to the
design of a kernel based crash dump capture implementation. How does
the crashdump capture process discover relevant information about the
kernel that just crashed? There are two options.
1) As represented by the current crashdump patches the crashdump
kernel and the kernel in which it loads are kept in sync so that
it has uptodate versions all of crashed kernels data structures
because it is built from the same source. So it only needs to
find the address of the data structures it would like to look at.
2) The relevant information if it is available when sys_kexec_load
is called is exported to user space, or the machine_crash_shutdown
method marshalls what little information must be captured when the
machine dies in a well known standard format (most likely ELF
notes). Allowing the crashdump capture process to simply pass
on the information or utilize it as appropriate.
If the second method can successfully represent all of the
interesting information then we can allow kernel version
skew, between the two kernels, and potentially implement
the entire crash dump capture process in user space.
As best as I have been able to discover the interesting information
includes. The cpu state (registers) at the time of the crash/panic.
The list of memory regions the kernel that has crashed was using.
And potentially the list of pages dedicated to kernel data as opposed
to user space, so the the people with insane amounts of memory (1TB+)
don't require unmanagely large core files.
Andrew earlier when asked about the possibility of merghing the kexec
on panic code you said:
> I don't want us to be in a position of merging all that code and then
> finding out that it cannot be made to work "sufficiently well",
> forcing us to revert it and find a new crashdump solution. You guys
> know far better than I when we will reach that threshold. If the
> kexec/dump developers can say "yup, this is going to work (because X)"
> then I'm happy.
So here is my subjective view.
- This code needs to sit in a development tree for a little while
to shake out whatever bugs still linger from my massive refactoring.
- Through the kexec patches the code and design appears to be sound.
Given that machine_kexec is little more than a jump there are few
possible implementations that will be able to use it. The only
exception I can see are running special dump drivers from the kernel
that crashed, and I believe no one thinks the that will work well.
- Once we finish sorting out the best way to get information out of
the kernel that crashed I think we will have a complete architecture
that is largely portable to any architecture.
In the interests of full disclosure my main interesting is using the
kernel as a bootloader for other kernels and that has been working
fairly for years now :)
# Patches to remove from 2.6.11-rc1-mm1 before applying this patchset:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/