What's Inside a Linux Kernel Core Dump(blogs.oracle.com)
blogs.oracle.com
What's Inside a Linux Kernel Core Dump
https://blogs.oracle.com/linux/post/whats-inside-a-linux-kernel-core-dump
22 comments
> Like a more specialized piece of code that only handles kernel coredumps?
Can't the kdump kernel be exactly that?
You can build a second kernel separate from the normal one, that only has the necessary options enabled to handle the coredump stuff. This way it can be relatively small and you can reuse the required driver code.
Can't the kdump kernel be exactly that?
You can build a second kernel separate from the normal one, that only has the necessary options enabled to handle the coredump stuff. This way it can be relatively small and you can reuse the required driver code.
Is that what it is?
That is in fact how crash dump works on illumos systems. Once you enter a kernel panic, interrupts are disabled, all other CPUs are brought to rest, etc. Then the panic code takes the pages to write to the dump and passes them to a special routine in the driver for the dump device: usually either a slice on a disk or a zvol). That driver is responsible for getting the device into a state where polled I/O can be performed, and to write the pages out. At the end the system reboots, and on the next boot a program called savecore inspects the dump device to see if there is a new dump, and if there is it transfers it into a new file.
FreeBSD does the same thing (probably some shared 80s BSD heritage?). One challenge is actually providing that special routine for the dump device in a way that is safe at crash time. You don't know how bad a state your crashed kernel is in, and some buses may not have a polled IO mode (USB?).
The Linux kexec process kind of elegantly restarts into a known state, with the known drawback of hogging some memory. It's definitely a different set of tradeoffs and both seem vaguely reasonable.
The Linux kexec process kind of elegantly restarts into a known state, with the known drawback of hogging some memory. It's definitely a different set of tradeoffs and both seem vaguely reasonable.
[deleted]
> Is there really no better way to do this than to have an entire second kernel
> ready to take over? Like a more specialized piece of code that only handles
> kernel coredumps?
So the requirements of this software are: It must be able to boot a system, write to the specific sections of memory, have some method of initializing hardware, some ability to write the other memory to disk or network connections. It sounds like you're talking about an OS.
I believe this is exactly what KDUMP does.
So the requirements of this software are: It must be able to boot a system, write to the specific sections of memory, have some method of initializing hardware, some ability to write the other memory to disk or network connections. It sounds like you're talking about an OS.
I believe this is exactly what KDUMP does.
The crash dumper only needs to write to disk or network. The other steps are just things the kexec process does to achieve that aim.
No, this is not true. If you just boot like a regular operating system, you will trash the crashed kernel making the dump useless.
A crash dumper does not have to be implemented with a reboot; this is just something Linux chooses to do. I have actually worked on kernel code that performs crash dumps to disk and over the network, if you find that kind of expertise relevant.
I really do.
I believe kexec/kdump does execute in place and does not go through a full reboot, am I wrong ?
I believe kexec/kdump does execute in place and does not go through a full reboot, am I wrong ?
OpenVMS on x86 implements kernel crash dumping in more or less the same way as Linux. See Chapter 6 of https://docs.vmssoftware.com/docs/vsi-openvms-x86-64-boot-ma...
Is it just me that feels dirty learning about the linux kernel from an Oracle page?
For what it's worth, Oracle is one of the largest contributors to the kernel, especially if you filter out the drivers subtree, which tends to skew the metrics for various reasons (lots of large generated code, almost identical arm SoC variants etc)
It would be really odd if they couldn't teach you about the kernel.
It would be really odd if they couldn't teach you about the kernel.
As a counter-example, Zstd is created and primarily developed by a Meta employee.
I also felt the same way upon opening the article, but companies are made of individuals, and often individuals do valuable and insightful work, even inside of bureaucratic and Kafkaesque organizations like Oracle.
I also felt the same way upon opening the article, but companies are made of individuals, and often individuals do valuable and insightful work, even inside of bureaucratic and Kafkaesque organizations like Oracle.
It's just you.
No. It's not. I'm glad someone shared this feeling because I had it too.
Feels wrong, but the information density and presentation are pretty good for this. Easy to understand I think.
A bit, but there's plenty of very smart people there, and this particular page seems controlled by the engineers and not the leadership.
Is there really no better way to do this than to have an entire second kernel ready to take over? Like a more specialized piece of code that only handles kernel coredumps?