Hi Ken'ichi, On 2011-07-15 14:20:41 Fri, Ken'ichi Ohmichi wrote: > > Hi Mahesh, > > (I'm back to makedumpfile devel for merging this patchset, > because Tachibana-san is busy.) Good to see that you are back. > > 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. 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. > > 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 Thanks, -Mahesh. > > _______________________________________________ > kexec mailing list > kexec at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec -- Mahesh J Salgaonkar
