Itsuro Oda <[EMAIL PROTECTED]> writes: > Hi, > > On 02 Feb 2005 07:45:11 -0700 > [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > > > > And the feedback begins :) > > > > Itsuro Oda <[EMAIL PROTECTED]> writes: > > > > > Hi, > > > > > > I don't like calling crash_kexec() directly in (ex.) panic(). > > > It should be call_dump_hook() (or something like this). > > > > > > I think the necessary modifications of the kernel is only: > > > - insert the hooks that calls a dump function when crash occur > > crash_kexec() > > > - binding interface that binds a dump function to the hook > > > (like register_dump_hook()) > > sys_kexec_load(...); > > For example there are pepole who want to execute a built in kernel > debugger when the system is crashed. or there are pepole who > believe the diskdump is the best dump tool :-) > > So I think a sort of hook is better than calling crash_kexec > directly. (May I make a patch ?)
The prevalent feeling I have heard from kernel developers and and my personal feeling as well is that after a kernel has called panic you can't trust it. Which means anything running in the kernel itself is suspect. The crash_kexec() hooks enables everything that does not get linked into the kernel. So I don't feel a hook in the panic path is necessary nor do I feel that it is wise, especially with no in-kernel users. Plus the worst part about a hook in the panic path is that it is inherently racy. Keeping the crash_kexec() code from blocking or being racy has been a challenge. And I still think that entire code path needs a review and some more code tweaks to remove races. If someone else wants a hook in the panic path they can add their own hook, and make their own case for why it is needed. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
