To: vgoyal@in.ibm.com
Cc: Morton Andrew Morton <akpm@osdl.org>,
       Anderson Dave Anderson <anderson@redhat.com>,
       Fastboot mailing list <fastboot@lists.osdl.org>,
       linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO to
 kernel core dumps
References: <20050921065633.GC3780@in.ibm.com>
	<m1mzm6ebqn.fsf@ebiederm.dsl.xmission.com>
	<20050922073914.GA3753@in.ibm.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 22 Sep 2005 03:11:40 -0600
In-Reply-To: <20050922073914.GA3753@in.ibm.com> (Vivek Goyal's message of
 "Thu, 22 Sep 2005 13:09:14 +0530")
Message-ID: <m18xxpcvqr.fsf@ebiederm.dsl.xmission.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3791
Lines: 89

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Wed, Sep 21, 2005 at 08:28:32AM -0600, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@in.ibm.com> writes:
>> 
>> > o This patch adds a new note type NT_KDUMPINFO. This note is added with 
>> >   kernel core dumps generated by kdump.
>> >
>> > o This note mainly communicates the information required by kernel dump
>> > analysis tool "crash" to analyze the kernel core dump. As of now it contains
>> >   the pointer to task struct of panicing task and page size. Page size is 
>> > irrelevant for i386 but is required for architectures like ia64 and ppc64.
>> >
>> > o gdb is not affected by this change as gdb need not to parse this note.
>> 
>> A couple of things.
>> - The name of your note is terribly generic, so it seems a poor choice.
>> 
>
> Yes it seems generic. And I think the reason being that I did not have a
> significant number of things to report hence could not create logical groups
> and giving very specific names to those groups. As of today, based on the
> requirements, could think of only two items (page size, current). There
> is still scope for few more things to appear. Hence gave a generic name and
> thought more items can be grouped in this note itself until and unless group
> becomes really big and need to break.

I'm not certain exactly how but we do need to capture the kernel version
so we can verify the vmlinux binary and the core dump match.

> Do you have any suggestion to make this name better?

Not presently.  That still doesn't mean it isn't worth brain storming
about.

>> - Why do we need to capture the page size at the time of the
>>   crash?  Isn't the page size a compile time option?  Won't
>>   sys_getpagesize() get you this information before the crash?  
>>   Why do we need the kernels page size at all?
>> 
>
> Dave has already mentioned about the need of page size. I agree that page
> size is a compile time information. Are you hinting at creating a separate
> note for reporting page size in user space while loading the capture kernel 
> and store it in reserved region alongside other elf headers. Not sure, if
> it is good to create a separate note type just to report one configuration
> variable. 

It's in my reply to Dave but we need a way to get that kind of information
out of vmlinux.

>> - Why do you avoid storing the current task on the other cpus?
>> 
>> - Can't we derive the current task from the existing register information
>>   already captured.  

In my reply to Dave I noted that flagging the cpu is cheaper and more
reliably that returning current.

>> If not would a little extra debug information
>>   captured at compile time be better?
>> 
>
> Sorry, I did not get this. Can you elaborate a little more on this. What
> kind of debug information can be helpful in determining the current.

The dwarf2 debug information can tell you what registers a variable
is stored in.  I was thinking of something along those lines, for
reporting to the debugger where current was stored.

>> - You don't address the issue of architectural control registers.
>>   So you are going to need another note at some point. (Not 
>>   necessarily a bad thing).
>> 
>
> That's true. Probably a new note type shall be required to store
> architectural control registers. May be something like NT_KDUMP_CRREG and
> NT_KDUMPINFO can continue to capture miscellaneous info. 

Sounds right.  I am slightly less concerned so long as we restrict
ourselves to an append only discipline with regards to the information
in that note.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/