From mboxrd@z Thu Jan  1 00:00:00 1970
From: laijs@cn.fujitsu.com (Lai Jiangshan)
Date: Thu, 19 Feb 2009 18:56:43 +0800
Subject: [ltt-dev] Mini Design and Roadmap of LTT-Kdump
In-Reply-To: <20090219035807.GD7956@Krystal>
References: <49927519.5080609@cn.fujitsu.com> <20090219035807.GD7956@Krystal>
Message-ID: <499D3AEB.7010200@cn.fujitsu.com>

Mathieu Desnoyers wrote:
> * Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
>>
>> Mini Design and Roadmap of LTT-Kdump
>>
> 
> Hi Lai,
> 
> This sounds very interesting and useful !
> 
>> -----------
>> 	People in enterprise need to be able to diagnose why the system
>> failed. Failing once is acceptable from a customer perspective, but
>> failing again isn't. In this case, being able to extract the last events
>> before the crash can be very valuable and helps solving the problems
>> before they happen again.
>>
>> 	Create tools to simplify extraction of traces from crashed kernel.
>> The core file of crashed kernel is provided by kdump.
>> -----------
>>
>> 	We will implement it. This tool include two parts.
>>
>> Part1: Core-file analyser.
>> 	Analyse(needs kernel-debuginfo) the core-file and read
>> ltt-relay files.
>> 	This part will use elf-libs for analysing, but we use crash(8)
>> instead at first. crash(8) can simplify this work and crash(8) can perform
>> on a compressed core-file(http://sourceforge.net/projects/makedumpfile/).
>> 	When we use crash(8), we will write a gdb script for analysing.
>> crash(8) loads this gdb script, core-file and kernel-debuginfo then listens
>> to a pipe and does works.
>> 	crash(8) works very well when pages are vmap()ed into to a continuous
>> memmory region. But ltt-relay's pages are not vmap()ed, it'll very slow.
>> so we may use elf-libs or enhance crash(8) at last.
> 
> Why would it be so slow ? We don't have a contiguous memory mapping, but
> we have a linked list of pages we can walk. I am not very familiar with
> the crash(8) internals though, so there could be a limitation I do not
> foresee...

We use "append memory" to get memory:
append memory part2_pipe_name $buf->start $buf->start + $buf->chan->alloc_size
(this example for relay, not ltt-relay)

The length is not important, but if we call "append memory" millions times,
it will need several hours.

I use crash(8) instead hardcode to traveling structures in core-file by using
elf-libs. I hardly know elf-libs. I can learn it and use it.
But two things:

1) except un-vmaped pages, crash(8) does every thing well and simple.
example for traveling debugfs:
define debugfsls
        set $father = (struct dentry *)$arg1
        set $child_off = (size_t)&((struct dentry *)0)->d_u.d_child
        set $father_head = (void *)&$father->d_subdirs
        set $child_head = (void *)$father->d_subdirs.next
        while ($child_head != $father_head)
                set $child = (struct dentry *)($child_head - $child_off)
                if ($child->d_inode->i_fop == &relay_file_operations)
                        __dump_dentry__ $arg0 $RELAY_FILE $child
                end
                if (($child->d_inode->i_sb->s_magic == $DEBUGFS_MAGIC) && \
                                (($child->d_inode->i_mode & $S_IFDIR) != 0))
                        __dump_dentry__ $arg0 $DEBUGFS_DIR $child
                end
                set $child_head = (void *)$child->d_u.d_child.next
        end
        append value $arg0 $LIST_END
end

and crash(8) can handle several kinds of core-file.

2) Jobs should be done by professional guys.
   My code will be migrated to elf-libs very easy if anyone need.
   I will wait elf-professional to implement it or I implement it at last.

Lai