Failed to core dump with send_sig(task, SIGSEGV, 1) from Linux kernel

Question

I am working in an embedded Linux system, and now I want to trigger a core dump from within kernel by using send_sig(task, SIGSEGV, 1).

There is a process A having 10 threads, occasionally, there is a kernel oops occurred and at that time, one thread of A is the current process reported by kernel.

So I want to dump the core of the process A to find out what happened. So I did followings.

1. Enable core dump in kernel configuration.
2. Running ulimit -c unlimited in init script.
3. echo '/mnt/core.%p.%e' > /proc/sys/kernel/core_pattern.
4. Changed the kernel oops codes to call send_sig(task_A, SIGSEGV, 1) to send SIGSEGV to the process A.

Then I tried to reproduce the kernel oops, and I found the log of Segmentation Fault from process A, but I did NOT see any core dumped in /mnt/.

If I changed the process A to access 0 of address, it can trigger a core dump correctly.

Why it failed to dump core from my kernel codes (the process A did is killed by SIGSEGV)? And how can I trigger a core-dump to capture the user space context in the case of kernel oops???

Answer 1

I did more testing and found the root cause of failing to trigger process A core dumping with send_sig(xxxx) from within kernel.

process A is a background daemon which is launched by init script. The setting of ulimit -c unlimited is ran after process A is started, so the core dump setting did not take effect on process A.

So I stopped running process A from init script, and started it after running ulimit -c unlimited, than I can get the core dumped correctly.

Answer 2

Core dumps are really for debugging user-space processes; Linux kernel oopses should never happen. It thus seems likley that the kernel is force-killing the process, rather than allowing it to produce a coredump. I certainly couldn't find any resources on generating process core dumps on a kernel oops. OOPS'es are kernel bugs; and significant ones.

In principle, therefore, the correct way to debug a process that produces a kernel oops is to fix the oops itself. Enable the "panic_on_oops" option, set up kdump to retrieve the kernel dump, and then debug that. I believe kdump can also get the process dumps, if that's what you really want, but in truth finding and fixing the oops itself is the best way to go. If you're modifiying your kernel to try and send those signals and produce that coredump anyways, you might as well just fix the oops.