[PATCH v2 1/2] fadump: reduce memory consumption for capture kernel

[Michal Suchánek]

On Mon, 24 Apr 2017 18:26:37 +0530
Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:

> Hi Michal.
> 
> On Monday 24 April 2017 03:54 PM, Michal Suchánek wrote:
> > On Fri, 21 Apr 2017 00:19:55 +0530
> > Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:
> >  
> >> On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:  
> >>> On Wed, 19 Apr 2017 14:19:47 +1000
> >>> Michael Ellerman <mpe at ellerman.id.au> wrote:
> >>>     

> >> With the fadump_append= approach I posted in this response thread,
> >> additional parameters are enforced when fadump is active. If f/w
> >> supports appending additional parameters, it has to update
> >> chosen/bootargs whenever fadump is active. Almost the same thing
> >> except the dirty job is now done by f/w? Hence I thought
> >> fadump_append= kernel parameter approach is simple and lesser of
> >> the two evils? Am i missing something here..
> >>  
> > The firmware already has to set the parameter by which the kernel
> > can tell it is a fadump kernel. Hence it already modifies the
> > devicetree for fadump and you have to rely on it to do so.  
> 
> Right, devicetree is modified to include new 'ibm,kernel-dump' rtas
> node informing that fadump is active.
> 
> > The handover area which stores the additional parameters is
> > reserved by the running kernel so now you also have to rely on the
> > running kernel, the running kernel and fadum kernel having the same
> > idea about the location of handover area, the crashing kernel not
> > randomly overwriting the handover area, etc.
> >
> > In short it is additional potential for trouble which can be
> > avoided.
> >
> > I don't know if the firmware does protect the fadump reserved area
> > and devicetree from being randomly overwritten by the crashing
> > kernel but it is in the position to do so if desired. The handover
> > area is controlled by the crashing kernel and cannot have this
> > guarantee.
> >
> >  
> 
> I thinks there is a mixup here..
> I am no longer batting for handover area approach but
> "fadump_append=" approach (suggested by Michael Ellerman in this
> thread) where there is no need for a handover area but an additional
> kernel parameter fadump_append=numa=off,nr_cpus=1.. which is a comma
> separated list of parameters the user wants to enforce when fadump is
> active.
> 
> I was trying to say that passing additional parameters with
> 'fadump_append=' kernel parameter is better over f/w changing the
> chosen/bootargs node.


Ok, so a fadump specific parameter was just removed in
25031865553e5a2bd9b6e0a5d044952cfa2925d8 and with this we get one back.
If this is going to be added as an extra kernel parameter can't this be
passed to kdump kernel as well? Does kdump not have the same
restrictions?

Thanks

Michal