[PATCH v2 0/8] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore

[Ken'ichi Ohmichi]

Hi Mahesh,

Thank you for quick response.

On Fri, 15 Jul 2011 12:40:29 +0530
Mahesh J Salgaonkar <mahesh at linux.vnet.ibm.com> wrote:
> > > 
> > > The current approach is to re-run the makedumpfile on the crash dump
> > > (generated in the second kernel) when we are back into production kernel
> > > (1st kernel).
> > 
> > IIUC, there are be 2 dumpfiles on customer site by the above approach.
> > The one is with privacy/secret data, and another is without.
> 
> Correct.
> 
> > 
> > If correct, I like this approach because a customer can have two options
> > when the crash utility cannot read a dumpfile without privacy/secret data
> > on support site.
> 
> The crash utility would just display a warning message early on during
> invocation. Most of the time crash tool will be able to read/analyze the
> dump unless someone scrubs out the data on which crash utility is dependant
> on. And as I mentioned previously, this is intended just as a security filter
> and not to be used as detrimental to crash's analysis of the dump.

I see, this feature will not be a problem in most cases.
However a customer can create unreadable dumpfile by using this feature,
and current makedumpfile does not have such feature.

Of course unreadable dumpfile is due to wrong makedumpfile.conf,
and I like this feature anyway because a customer has options.


Thanks
Ken'ichi Ohmichi

> > First option:
> >   For digging a problem, a customer sends a dumpfile with privacy/secret
> >   data to support site.
> > 
> > Second option:
> >   For protecting privacy/secret data, a customer gives up digging a problem.