linux-kernel - Re: [patch 0/9] kdump: Patch series for s390 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110713200004.GG4426@redhat.com>
Date:	Wed, 13 Jul 2011 16:00:04 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
	ebiederm@...ssion.com, hbabu@...ibm.com, mahesh@...ux.vnet.ibm.com,
	oomichi@....nes.nec.co.jp, horms@...ge.net.au,
	heiko.carstens@...ibm.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org
Subject: Re: [patch 0/9] kdump: Patch series for s390 support

On Wed, Jul 13, 2011 at 06:46:11PM +0200, Martin Schwidefsky wrote:

[..]
> > 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.
> 
> My problem with that is the following: how do we get from the "Kernel Crash"
> step to the purgatory code? It does work for "normal" panics, but it fails
> miserably for a hard crash that does not even get as far as panic. That is
> why we insist on a possible second order of things:

What is hard crash? How does that happen and what does x86 and s390
do in that case?

Though I don't have details but your argument seems to be that in s390
we are always guranteed that we will jump to IPLing the stand alone
tools code irresepective of the system state hence it is relatively
safer to do checks in stand alone tools instead of purgatory where
code is in memory.

If due to hard hang, code can not even make to purgatory, where would
it go? Can't we do IPLing of stand alone tool then. 

So we first try to take purgatory path which does the checksum and is
consistent with other architectures. If that does not work in case
of hard hang, you always have the option of IPLing the stand alone tool
later manually.

This will also get rid of requirement passing all the segment and cheksum
info to stand alone tool with the help of meminfo (That's another sore
point). 

Bottom line, even if you can't make to purgatory reliably, you always
have the option of capturing dump manually using stand alone tools. We
don't have to mix up kdump and stand alone mechanism. If kdump fails, we
just need to have capability to still capture the dump using stand alone
tools manually. I think that will make things simpler even for stand alone
tools.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/