public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org, crash-utility@redhat.com,
	kexec@lists.infradead.org
Cc: oomichi@mxs.nes.nec.co.jp, "Luck, Tony" <tony.luck@intel.com>,
	tachibana@mxm.nes.nec.co.jp, Andi Kleen <andi@firstfloor.org>,
	anderson@redhat.com, "Eric W. Biederman" <ebiederm@xmission.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: [Patch 3/4][makedumpfile] Capture slimdump if elf-note NT_NOCOREDUMP present
Date: Mon, 3 Oct 2011 13:07:35 +0530	[thread overview]
Message-ID: <20111003073735.GC22694@in.ibm.com> (raw)
In-Reply-To: <20111003070735.GJ2223@in.ibm.com>

The kernel decides to add a new elf-note of type NT_NOCOREDUMP for various
hardware error triggered crashes where it makes no sense (or sometimes
dangerous) to capture kernel memory into the dump. This patch teaches
'makedumpfile' tool needs to recognise the new elf-note type and act
accordingly.

Since only a 'slimdump' of a very small size (containing only elf-headers and
elf-notes section) will be captured, the coredump will be of ELF type (and not
kdump-compressed format).

Todo: Make changes to the man pages of makedumpfile to describe these changes.

Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
 elf_info.c     |   36 ++++++++++++++++++++++++++++++++++++
 elf_info.h     |    8 ++++++++
 makedumpfile.c |   13 ++++++++++++-
 makedumpfile.h |    1 +
 4 files changed, 57 insertions(+), 1 deletions(-)

diff --git a/elf_info.c b/elf_info.c
index 114dd05..de93d9a 100644
--- a/elf_info.c
+++ b/elf_info.c
@@ -287,6 +287,41 @@ offset_note_desc(void *note)
 	return offset;
 }
 
+/*
+ * The kernel generally adds an elf-note of type NT_NOCOREDUMP if the crash is
+ * due to a hardware error and when it makes no sense to read/store the
+ * crashing kernel's memory. In such a case, only a 'slimdump' is captured.
+ *
+ * This function checks if the elf-header has a note of type NT_NOCOREDUMP.
+ */
+int
+has_nocoredump_note(void)
+{
+	char note[MAX_SIZE_NHDR];
+	off_t offset;
+
+	offset = offset_pt_note_memory;
+	while (offset < offset_pt_note_memory + size_pt_note_memory) {
+		if (lseek(fd_memory, offset, SEEK_SET) < 0) {
+			ERRMSG("Can't seek the dump memory(%s). %s\n",
+			    name_memory, strerror(errno));
+			return FALSE;
+		}
+		if (read(fd_memory, note, sizeof(note)) != sizeof(note)) {
+			ERRMSG("Can't read the dump memory(%s). %s\n",
+			    name_memory, strerror(errno));
+			return FALSE;
+		}
+		if (note_type(note) == NT_NOCOREDUMP) {
+			DEBUG_MSG("kdump will not be collected. "
+				  "NT_NOCOREDUMP elf-note present.\n");
+			return TRUE;
+		}
+		offset += offset_next_note(note);
+	}
+	return FALSE;
+}
+
 static int
 get_pt_note_info(void)
 {
@@ -630,6 +665,7 @@ get_elf_info(int fd, char *filename)
 		ERRMSG("Can't find PT_NOTE Phdr.\n");
 		return FALSE;
 	}
+	has_nocoredump_note();
 	if (!get_pt_note_info()) {
 		ERRMSG("Can't get PT_NOTE information.\n");
 		return FALSE;
diff --git a/elf_info.h b/elf_info.h
index 4dff9c1..10fdc0b 100644
--- a/elf_info.h
+++ b/elf_info.h
@@ -22,6 +22,12 @@
 #define ERASEINFO_NOTE_NAME		"ERASEINFO"
 #define ERASEINFO_NOTE_NAME_BYTES	(sizeof(ERASEINFO_NOTE_NAME))
 
+/*
+ * Temporary definition of new elf-note type for compilation purposes.
+ * Not required when run on a new kernel containing this definition.
+ */
+#define NT_NOCOREDUMP	21
+
 #define MAX_SIZE_NHDR	MAX(sizeof(Elf64_Nhdr), sizeof(Elf32_Nhdr))
 
 
@@ -34,6 +40,8 @@ unsigned long long get_max_paddr(void);
 int get_elf64_ehdr(int fd, char *filename, Elf64_Ehdr *ehdr);
 int get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr);
 int get_elf_info(int fd, char *filename);
+int has_nocoredump_note(void);
+
 void free_elf_info(void);
 
 int is_elf64_memory(void);
diff --git a/makedumpfile.c b/makedumpfile.c
index 7b7c266..a73b4f7 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -4173,7 +4173,11 @@ write_elf_pages(struct cache_data *cd_header, struct cache_data *cd_page)
 		if (!get_phdr_memory(i, &load))
 			return FALSE;
 
-		if (load.p_type != PT_LOAD)
+		/*
+		 * Do not capture the kernel's memory if flag_nocoredump is
+		 * turned on. This may be dangerous to the system stability.
+		 */
+		if ((load.p_type != PT_LOAD) || (info->flag_nocoredump))
 			continue;
 
 		off_memory= load.p_offset;
@@ -5760,6 +5764,13 @@ create_dumpfile(void)
 		if (!get_elf_info(info->fd_memory, info->name_memory))
 			return FALSE;
 	}
+	/*
+	 * If NT_NOCOREDUMP elf-note is present, indicate the same through
+	 * 'flag_nocoredump' flag. The resultant slimdump will always be in ELF
+	 * format, irrespective of the user options.
+	 */
+	info->flag_nocoredump = info->flag_elf_dumpfile = has_nocoredump_note();
+
 	if (is_xen_memory()) {
 		if (!initial_xen())
 			return FALSE;
diff --git a/makedumpfile.h b/makedumpfile.h
index f0e5da8..faf1c65 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -778,6 +778,7 @@ struct DumpInfo {
 	int		flag_exclude_xen_dom;/* exclude Domain-U from xen-kdump */
 	int             flag_dmesg;          /* dump the dmesg log out of the vmcore file */
 	int		flag_nospace;	     /* the flag of "No space on device" error */
+	int		flag_nocoredump;	/* coredump not collected */
 	unsigned long	vaddr_for_vtop;      /* virtual address for debugging */
 	long		page_size;           /* size of page */
 	long		page_shift;
-- 
1.7.4.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2011-10-03  7:38 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03  7:07 [Patch 0/4] Slimdump framework using NT_NOCOREDUMP elf-note K.Prasad
2011-10-03  7:32 ` [Patch 1/4][kernel][slimdump] Add new elf-note of type NT_NOCOREDUMP to capture slimdump K.Prasad
2011-10-03 10:10   ` Eric W. Biederman
2011-10-03 12:03     ` K.Prasad
2011-10-04  6:34       ` Borislav Petkov
2011-10-05  7:07         ` K.Prasad
2011-10-05  7:31           ` Borislav Petkov
2011-10-05  9:47             ` K.Prasad
2011-10-05 12:41               ` Borislav Petkov
2011-10-05 15:52               ` Vivek Goyal
     [not found]                 ` <10327.1317830438@turing-police.cc.vt.edu>
2011-10-05 16:16                   ` Borislav Petkov
2011-10-05 17:20                     ` Vivek Goyal
2011-10-05 17:13                   ` Vivek Goyal
     [not found]             ` <26571.1317815746@turing-police.cc.vt.edu>
2011-10-05 12:31               ` Borislav Petkov
2011-10-05 15:19           ` Vivek Goyal
2011-10-05 15:30           ` Vivek Goyal
2011-10-03 22:53     ` Luck, Tony
2011-10-04 14:04   ` Vivek Goyal
2011-10-05  7:18     ` K.Prasad
2011-10-05  7:33       ` Borislav Petkov
2011-10-05  9:23         ` K.Prasad
2011-10-05 15:25       ` Vivek Goyal
2011-10-07 16:12         ` K.Prasad
2011-10-10  7:07           ` Borislav Petkov
2011-10-11 18:44             ` K.Prasad
2011-10-11 18:59               ` Luck, Tony
2011-10-12  0:20               ` Andi Kleen
2011-10-12 10:44               ` Borislav Petkov
2011-10-12 15:59                 ` Vivek Goyal
2011-10-12 15:51               ` Vivek Goyal
2011-10-14 11:30                 ` K.Prasad
2011-10-14 14:14                   ` Vivek Goyal
2011-10-18 17:41                     ` K.Prasad
2011-10-11 18:55             ` Luck, Tony
2011-10-04 14:30   ` Vivek Goyal
2011-10-05  7:41     ` K.Prasad
2011-10-05 15:40       ` Vivek Goyal
2011-10-05 15:58         ` Luck, Tony
2011-10-05 16:25           ` Borislav Petkov
2011-10-05 17:10           ` Vivek Goyal
2011-10-05 17:20             ` Borislav Petkov
2011-10-05 17:29               ` Vivek Goyal
2011-10-05 17:43                 ` Borislav Petkov
2011-10-05 18:00                 ` Dave Anderson
2011-10-05 18:09                   ` Vivek Goyal
2011-10-04 15:04   ` Nick Bowler
2011-10-07 16:36     ` K.Prasad
2011-10-07 18:19       ` Nick Bowler
2011-10-03  7:35 ` [Patch 2/4][kexec-tools] Recognise NT_NOCOREDUMP elf-note type K.Prasad
2011-10-03  7:37 ` K.Prasad [this message]
2011-10-03  7:45 ` [Patch 4/4][crash] Recognise elf-note of type NT_NOCOREDUMP before vmcore analysis K.Prasad

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=20111003073735.GC22694@in.ibm.com \
    --to=prasad@linux.vnet.ibm.com \
    --cc=anderson@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=crash-utility@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oomichi@mxs.nes.nec.co.jp \
    --cc=tachibana@mxm.nes.nec.co.jp \
    --cc=tony.luck@intel.com \
    --cc=vgoyal@redhat.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