[lkml]   [2011]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/9] kdump: Patch series for s390 support
    On Mon, Jul 11, 2011 at 05:56:26PM +0200, Martin Schwidefsky wrote:

    > > kexec-tools purgatory code already has the checksum logic. So you don't
    > > have to redo that in stand alone tools. I think you probably need to
    > > s390 specic purgatory and jump to IPLing stand alone kernel if kdump
    > > kernel is corrupted instead of rebooting back or spinning infinitely
    > > in the loop/
    > I can not quite follow you here. The purgatory code is part of the kdump kernel,
    > no? When we trigger a dump with the stand-alone tools we will start executing
    > code in the assembler function of that stand-alone tools. We can not trust
    > the kdump kernel yet, not without doing the checksums first.

    Purgatory is another piece of binary code which is loaded along with kdump
    kernel in reserved memory area. So yes, there is a chance that this code
    itself get corrupted.

    So in case of stand alone dump, you save the calculated checksum of
    kdump kernel at disk and not in memory? And then calculate the checksum
    of memory image of kdump kernel and decide whether kdump kenrel is
    corrupted or not?

    If yes, this sounds more reliable as checksum of kernel is stored on
    some disk/tape.

    > > Ok. So again why not reuse the checksump capability of kexec-tools and
    > > instead of infinite looping you can jump to stand alone tools + IPL etc.
    > > I understand this will require a tighter integration with kexec-tools
    > > and using ELF header mechanism and will not cover the early kernel
    > > crashes.
    > Imho the checksum of kexec-tools is in the wrong place.

    Because you think that stored checksum can get corrupted?

    > > To me we seem to be diverging a lot from existing kdump+kexec-tools
    > > mechanism just to solve the case of early crash dumping. If we break
    > > down the problem in two parts and do thing kexec-tools way (with a
    > > backup path of booting stand alone kernel if kdump kenrel is corrupted),
    > > things might be better.
    > The "backup path of booting stand alone kernel" would result in passing
    > the control twice, once from the stand-alone dumper to the kexec purgatory
    > (after the purgatory checksum has been verified), then doing more checks
    > in the kdump kernel, only to return to the stand-alone dumper if some check
    > fails. Does not really sound enticing to me.

    What I am suggesting is that stand alone dumper gets control only if
    kdump kernel is corrupted.

    So following sequence.

    Kernel Crash ---> purgatory --> either kdump kenrel/IPL stand alone tools

    Here only drawback seems to be that we assume that purgatory code and
    pre-calculated checksum has not been corrupted. The big advantage is
    that s390 kdump support looks very similar to other arches and
    understaning and supporting kdump across architectures becomes easy.


     \ /
      Last update: 2011-07-13 18:11    [W:0.021 / U:33.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site