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
