On 06/07/2017 09:46 AM, Eric W. Biederman wrote:
Daniel Walker <[email protected]> writes:
Hi,
These two paths seem to be duplicating each other. We have an issue
where we're using mtdoops to collect kernel logs on oops and panic, we
also have a crash kernel (which also collects these logs). mtdoops
saves logs differently for oops and panic, since oops isn't always
fatal it schedules a write to the flash. Since panic() is always fatal
is writes the logs immediately. In oops_end() the crash kernel runs
immediately while still signaling an OOPS condition to mtdoops. Since
mtdoops schedules a write to flash later, there is no later since the
crash kernel runs immediately, we end up without getting the logs
I'm wondering what the significance is to have these two paths ?
oops_end() could just call into panic() or a modified
panic_with_regs() then we would collapse multiple paths. There is what
I would call a hack in kexec_should_crash() which checks if there are
crash_kexec_post_notifiers and it runs panic() if they exist. This
wouldn't be needed if we always called panic() . I also wonder if
there are other things in panic() which we should be running , but
don't get run because of these two paths.
crash_kexec_post_notifiers is a horrible hack it is broken by design and
no one should use it.
Looking at the history and it still seems valid is the point of
kexec_should_crash is so that crash_kexec could be called with the
registers at the time of the crash.
This is why I mention panic_with_regs() , it's not that hard to just
send them into panic().
The code that is run in kexec on panic path the less well it works.
This has been a known fact for years.
Please figure out how to depend on less code running in a broken
kernel. Trying to figure out how to run more code is not the solution
to making the kernel reliable at the time of a crash.
Eric
While this may be true, your cutting short an already existing panic()
path which has been around and is well used. I would think if it's good
enough for everyone else it should be good enough for the crash kernel path.
Daniel
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
