[patch v2 04/10] kdump: Trigger kdump via panic notifier chain on s390

[Michael Holzheu]

Hello Vivek,

On Thu, 2011-08-04 at 17:14 -0400, Vivek Goyal wrote:
> On Wed, Aug 03, 2011 at 11:50:39AM +0200, Michael Holzheu wrote:

[snip]
 
> > Only if the user has specified panic action stand-alone dump, we do the
> > detour via the stand-alone dump tools.
> 
> If a user decides to load kdump kernel to capture dump, then why does it
> still make sense to set panic action as "stand-alone dump tools". One
> could argue that user loaded kdump kernel but not necessarily wants
> that mechanism to use, in that case dump-tools does not have to jump
> to kdump kernel at all. 

The user on s390 can currently freely configure the panic action. If we
would always do kdump on panic, when kdump is active, we would have to
ensure in sysfs that the user can't change the setting any more.
Technically we could do that of course.

One use case we had in mind was that the s390 Linux administrator does
not have to learn new things when using kdump. kdump can be used as
extension of the already existing mechanism. Today users configure
stand-alone dump via sysfs. With kdump + trigger via dump tools they
could do it still the same way. And also for manual dump they just IPL
the dump tool as they are used to do it and if kdump is fine, kdump will
be triggered. Nothing new has to be learned.

If users only want to use kdump without stand-alone dump tools as on
other architectures also this is possible. Then the panic action will be
just kdump.

> > 
> > > like other architectures and jump to stand
> > > alone kernel only if some piece of code is corrupted and that action
> > > failed.
> > > 
> > > What's the point of jumping to stand alone kenrel in case of panic()
> > > and then re-enter it back to original kernel using crash_kexec(). Sound
> > > like a very odd design choice to me.
> > > 
> > > I am now I am repeating this question umpteen time simply because
> > > I never got a good answer except "we have to do it this way".
> > 
> > Sometimes communication is really hard and frustrating.
> > ... but at least we are still communicating.
> > 
> > Ok very last try:
> > 
> > * We can use the same mechanism for manual dump and automatic dump on
> > panic: IPL the stand-alone dump tools.
> 
> So manual dump/intervention is only required if automatic dump failed?

Manual intervention is required only if panic code does not make it to
the "IPL stand-alone dump tools" code.

> 
> > kdump check and backup
> > stand-alone dump is implemented only in the stand-alone dump code.
> 
> My argument is that why stand alone dump is trying to trigger kdump
> at all? Shouldn't it all be part of loading kdump kernel and user
> setting panic() action to kdump?

To summarize: Our approach was to do it in the stand-alone dump tools
code for both the manual and the automatic on panic case:

panic ------+                                 +- valid -> kdump
            +-> IPL dump tools -> try kdump --+
hard hang --+                                 +- invalid -> stand-alone dump

Your suggestion looks like the following:

panic --> try kdump +-- valid ---> kdump
                    |
                    +-- invalid -> IPL dump tools --> stand-alone dump

                                            +- valid -> kdump
hard hang --> IPL dump tools -> try kdump --+ 
                                            +- invalid -> stand-alone dump

Is that what you are suggesting? We can do it that way, too. Then
we would not need the #ifdef CONFIG_S390 in panic().

Michael