Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

[Eric W. Biederman]

Itsuro Oda <oda@xxxxxxxxxxxxx> writes:

> Hi,
> 
> On 02 Feb 2005 07:45:11 -0700
> ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:
> 
> > 
> > And the feedback begins :)
> > 
> > Itsuro Oda <oda@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/