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

[Ken'ichi Ohmichi]

Hi Mahesh,

(I'm back to makedumpfile devel for merging this patchset,
 because Tachibana-san is busy.)

Sorry for replying an old mail.

On Fri, 27 May 2011 12:26:21 +0530
Mahesh J Salgaonkar <mahesh at linux.vnet.ibm.com> wrote:
> On 2011-05-26 09:39:23 Thu, Vivek Goyal wrote:
> > On Thu, May 26, 2011 at 01:15:14PM +0200, Reinhard Buendgen wrote:
> > > Vivek,
> > > 
> > > I/O is not restricted to disk I/O (it may be network I/O, data sent to 
> > > crtypto cards etc.) and it is not always direct, Device drivers may have 
> > > buffers to which such data is copied. 
> > > 
> > > So it is more than just keys, and it may change over time.
> > > I do not think hardwiring a filter in makedumpfile is a good idea because 
> > > you would need a new makedumpfile release for every Distribution 
> > > (release).
> > 
> > Ok, so we are worried about data being in slub/slab caches or driver's
> > kmalloced buffers etc.
> > 
> > When do I need access to debuginfo files. I am assuming that makedumpfile
> > reads them in first kernel sometime and stores relevant info in initramfs.
> > Otherwise, it is not possible to get to it in second kernel after crash.
> > 
> 
> 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.

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.

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.


Thanks
Ken'ichi Ohmichi