public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Anderson <anderson@redhat.com>
To: vgoyal@in.ibm.com
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Morton Andrew Morton <akpm@osdl.org>,
	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 tokernel   core dumps
Date: Thu, 22 Sep 2005 11:06:36 -0400	[thread overview]
Message-ID: <4332C87C.9CE47E8D@redhat.com> (raw)
In-Reply-To: 20050922140824.GF3753@in.ibm.com

Vivek Goyal wrote:

>
> > Ok.  The point here is to know which task/cpu called panic, rather
> > than to get the task_struct.   That makes a lot of sense, and is
> > cheap to get.  Any note on the crashing cpu that is not captured
> > by another cpu will give us that information.
> >
>
> That makes sense. Sheer presence of a particular note can identify the
> crashing cpu and no need to store "current". Only crashing cpu is going
> to store that note and that too after respective NT_PRSTATUS.
>
> > My primary concern is while the concept of a task_struct is pretty
> > stable who is to know how the kernel will change in the future.  So
> > if we don't need to export a task_struct pointer and merely need
> > to flag the cpu that called panic we can do that much more reliably.

Just flagging the cpu, and then mapping that to the stack pointer found in
the associated NT_PRSTATUS register set should work OK too.  It gets
a little muddy if it crashed while running on an IRQ stack, but it still can be
tracked back from there as well.  (although not if the crashing task overflowed
the IRQ stack)

The task_struct would be ideal though -- if the kernel's use of task_structs
changes in the future, well, then crash is going to need a serious re-write
anyway...  FWIW, netdump and diskdump use the NT_TASKSTRUCT note
note to store just the "current" pointer, and not the whole task_struct itself,
which would just be a waste of space in the ELF header for crash's purposes.
And looking at the gdb sources, it appears to be totally ignored.  Who
uses the NT_TASKSTRUCT note anyway?

>
> > We do need a way that we can test to see if a core dump
> > actually matches the vmlinux we are looking at.  Probably
> > this is capturing all of the information captured by linux/version.h
> > and linux/compile.h both at runtime and at compile time and
> > checking to see if they match.
> >
>
> I quickly browsed through "crash" code and looks like it is already doing
> similiar check (kernel.c, verify_version()). It seems to be retrieving
> "linux_banner" from core image and also retrieving banner string from vmlinux
> and trying to match. So if banner information can be directly read from the
> core image, probably there is no need to export it through notes.
>

That's correct.

Dave



  reply	other threads:[~2005-09-22 15:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21  6:56 [PATCH] Kdump(x86): add note type NT_KDUMPINFO to kernel core dumps Vivek Goyal
2005-09-21 14:28 ` [Fastboot] " Eric W. Biederman
2005-09-21 15:17   ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernel " Dave Anderson
2005-09-22  9:01     ` Eric W. Biederman
2005-09-22 14:08       ` Vivek Goyal
2005-09-22 15:06         ` Dave Anderson [this message]
2005-09-22 16:31           ` Eric W. Biederman
2005-09-22 20:33             ` Haren Myneni
2005-09-23  5:09             ` Vivek Goyal
2005-09-23  7:22               ` Eric W. Biederman
2005-09-23 15:17               ` Subject: [PATCH] Don't uselessly export task_struct to user space in " Eric W. Biederman
     [not found]             ` <OF0A1E6B6F.F00DC760-ON87257084.005F99D6-88257084.00634A38@us.ibm.com>
2005-09-23  5:19               ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernel " Vivek Goyal
     [not found]               ` <4332FD56.2F5256F5@redhat.com>
2005-09-23  7:12                 ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernelcore dumps Eric W. Biederman
2005-09-23 12:01                   ` Vivek Goyal
2005-09-26  6:29                   ` Vivek Goyal
2005-09-22 16:38         ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO tokernel core dumps Eric W. Biederman
2005-09-22 17:00           ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFOtokernel " Dave Anderson
2005-09-22  7:39   ` [Fastboot] [PATCH] Kdump(x86): add note type NT_KDUMPINFO to kernel " Vivek Goyal
2005-09-22  7:46     ` Andrew Morton
2005-09-22  8:32       ` Vivek Goyal
2005-09-22  9:11     ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4332C87C.9CE47E8D@redhat.com \
    --to=anderson@redhat.com \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox