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

[Eric W. Biederman]

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(...);
> - supply the information of valid physical address regions
/proc/iomem or possibly /proc/cpumem.  At least until someone
actually implements hot plug memory support.

> (- maybe some existent functions and variables need to be exported ?)
> 
> I think this makes any sort of dump functions can be implemented
> as a kernel module. I don't think it is best way that the "kexec based 
> crashdump" is built in the kernel.

For people developing code outside of the kernel I can see where
this is a problem.  Given the insane auditing requirements necessary
to get a reliable code path I don't see how not putting the implementation
in the kernel is sane.  Anything that needs to be touched at that point
is core kernel functionality GPL_ONLY if it is exported at all.
Touching anything from a module at that point is not sane.

Basically the code path setup with crash_kexec is little more
than a jump instruction.  And it should be audited and reduced
as much as possible.  I don't see how you get simpler or what
piece of functionality could possibly improve by having multiple
implementations in kernel modules.

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/