Re: [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernel core dumps

[Dave Anderson <anderson@redhat.com>]

"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.
> >

It's not absolutely required for crash -- but more of a convenience.  As it is, the
set of NT_PRSTATUS sections can be scoured for the set of active
tasks, and then the process stacks (and potentially the IRQ stacks, then
mapped back to the proper process stack) can be searched for crash_kexec.
So crash works without the task_struct pointer, but it's ugly.  It's just that
netdump, diskdump and LKCD all report the panic task_struct pointer,
and it seems a reasonable thing to do.

>
> > 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.
>
> - 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?
>

The page size is needed for a whole host of things, primarily for
virtual-to-physical address translations, a bunch of VM-related
commands, etc.  For non-x86[_64] systems. the host system may
be using a different page size than the vmcore being examining.
That's probably a rare situation, and using getpagesize() on the
host would work in most cases, or perhaps issuing the page size
as a command line option, but again, it's another convenience item
that gets reported by netdump, diskdump and LKCD.

>
> - Why do you avoid storing the current task on the other cpus?
>

They can be found in the per-cpu runqueues data structure.

>
> - Can't we derive the current task from the existing register information
>   already captured.  If not would a little extra debug information
>   captured at compile time be better?
>
> - 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).
>

I guess that's their whole point.  This NT_KDUMPINFO or whatever
you want to call it, could cumulatively collect any other data deemed
necessary that falls outside the bounds of the existing note types.

Dave Anderson

>
> > +/*
> > + * NT_KDUMPINFO can be used to communicate additional information required for
> > + * kernel core dumps. Additional information includes kernel configuration
> > + * variables like page size and any other relevant data required by
> > + * debugger (crash in this case).
> > +*/
> > +struct elf_kdumpinfo
> > +{
> > +     char page_shift;                /* Page size */
> > +     struct task_struct *panic_tsk;  /* Pointer to panic task_struct */
> > +};
> > +
>
> >  #define NT_TASKSTRUCT        4
> >  #define NT_AUXV              6
> >  #define NT_PRXFPREG 0x46e62b7f /* copied from gdb5.1/include/elf/common.h */
> > -
> > +#define NT_KDUMPINFO 7               /* Used for kernel core dumps */
> >

-
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/