From: Vivek Goyal <vgoyal@redhat.com>
To: Simon Horman <horms@verge.net.au>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>,
Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org, Chandru <chandru@in.ibm.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Terry Loftin <terry.loftin@hp.com>,
Paul Mundt <lethal@linux-sh.org>,
Paul Mackerras <paulus@samba.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Subject: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
Date: Mon, 28 Jul 2008 17:10:25 -0400 [thread overview]
Message-ID: <20080728211025.GA9985@redhat.com> (raw)
In-Reply-To: <20080728034007.GA30450@verge.net.au>
Hi All,
How does following series of patches look like. I have moved
elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
of crash dump to make sure that it can be worked with even when
CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
sh versions are completely untested.
Thanks
Vivek
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous kernel's TCE table. So even if
CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
correctly determine that we are booting after a panic and setup calgary
iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files.
(Unfortunately crash dump does not have an arch independent file otherwise
that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
second kernel without KEXEC being enabled.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
fs/proc/vmcore.c | 3 ---
include/linux/crash_dump.h | 14 ++++++++++----
2 files changed, 10 insertions(+), 7 deletions(-)
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore fs/proc/vmcore.c
--- linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 09:19:50.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c 2008-07-28 09:20:10.000000000 -0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
struct proc_dir_entry *proc_vmcore = NULL;
/* Reads a page from the oldmem device from given offset. */
diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore include/linux/crash_dump.h
--- linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 12:00:44.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h 2008-07-28 12:00:56.000000000 -0400
@@ -9,11 +9,7 @@
#define ELFCORE_ADDR_MAX (-1ULL)
-#ifdef CONFIG_PROC_VMCORE
extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
#define vmcore_elf_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
static inline int is_kdump_kernel(void)
{
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
_
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Simon Horman <horms@verge.net.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Muli Ben-Yehuda <muli@il.ibm.com>,
Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org, Chandru <chandru@in.ibm.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Terry Loftin <terry.loftin@hp.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Paul Mundt <lethal@linux-sh.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@ozlabs.org
Subject: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch]
Date: Mon, 28 Jul 2008 21:10:25 +0000 [thread overview]
Message-ID: <20080728211025.GA9985@redhat.com> (raw)
In-Reply-To: <20080728034007.GA30450@verge.net.au>
Hi All,
How does following series of patches look like. I have moved
elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
of crash dump to make sure that it can be worked with even when
CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
sh versions are completely untested.
Thanks
Vivek
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous kernel's TCE table. So even if
CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
correctly determine that we are booting after a panic and setup calgary
iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files.
(Unfortunately crash dump does not have an arch independent file otherwise
that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
second kernel without KEXEC being enabled.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
fs/proc/vmcore.c | 3 ---
include/linux/crash_dump.h | 14 ++++++++++----
2 files changed, 10 insertions(+), 7 deletions(-)
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore fs/proc/vmcore.c
--- linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 09:19:50.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c 2008-07-28 09:20:10.000000000 -0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
struct proc_dir_entry *proc_vmcore = NULL;
/* Reads a page from the oldmem device from given offset. */
diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore include/linux/crash_dump.h
--- linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 12:00:44.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h 2008-07-28 12:00:56.000000000 -0400
@@ -9,11 +9,7 @@
#define ELFCORE_ADDR_MAX (-1ULL)
-#ifdef CONFIG_PROC_VMCORE
extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
#define vmcore_elf_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
static inline int is_kdump_kernel(void)
{
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
_
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Simon Horman <horms@verge.net.au>
Cc: Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Terry Loftin <terry.loftin@hp.com>,
Paul Mundt <lethal@linux-sh.org>,
Paul Mackerras <paulus@samba.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Subject: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
Date: Mon, 28 Jul 2008 17:10:25 -0400 [thread overview]
Message-ID: <20080728211025.GA9985@redhat.com> (raw)
In-Reply-To: <20080728034007.GA30450@verge.net.au>
Hi All,
How does following series of patches look like. I have moved
elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
of crash dump to make sure that it can be worked with even when
CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
sh versions are completely untested.
Thanks
Vivek
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous kernel's TCE table. So even if
CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
correctly determine that we are booting after a panic and setup calgary
iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files.
(Unfortunately crash dump does not have an arch independent file otherwise
that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
second kernel without KEXEC being enabled.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
fs/proc/vmcore.c | 3 ---
include/linux/crash_dump.h | 14 ++++++++++----
2 files changed, 10 insertions(+), 7 deletions(-)
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore fs/proc/vmcore.c
--- linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 09:19:50.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c 2008-07-28 09:20:10.000000000 -0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
struct proc_dir_entry *proc_vmcore = NULL;
/* Reads a page from the oldmem device from given offset. */
diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore include/linux/crash_dump.h
--- linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 12:00:44.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h 2008-07-28 12:00:56.000000000 -0400
@@ -9,11 +9,7 @@
#define ELFCORE_ADDR_MAX (-1ULL)
-#ifdef CONFIG_PROC_VMCORE
extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
#define vmcore_elf_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
static inline int is_kdump_kernel(void)
{
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
_
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Simon Horman <horms@verge.net.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Muli Ben-Yehuda <muli@il.ibm.com>,
Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org, Chandru <chandru@in.ibm.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Terry Loftin <terry.loftin@hp.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Paul Mundt <lethal@linux-sh.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@ozlabs.org
Subject: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
Date: Mon, 28 Jul 2008 17:10:25 -0400 [thread overview]
Message-ID: <20080728211025.GA9985@redhat.com> (raw)
In-Reply-To: <20080728034007.GA30450@verge.net.au>
Hi All,
How does following series of patches look like. I have moved
elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
of crash dump to make sure that it can be worked with even when
CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
sh versions are completely untested.
Thanks
Vivek
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous kernel's TCE table. So even if
CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
correctly determine that we are booting after a panic and setup calgary
iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files.
(Unfortunately crash dump does not have an arch independent file otherwise
that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
second kernel without KEXEC being enabled.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
fs/proc/vmcore.c | 3 ---
include/linux/crash_dump.h | 14 ++++++++++----
2 files changed, 10 insertions(+), 7 deletions(-)
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore fs/proc/vmcore.c
--- linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 09:19:50.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c 2008-07-28 09:20:10.000000000 -0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
struct proc_dir_entry *proc_vmcore = NULL;
/* Reads a page from the oldmem device from given offset. */
diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore include/linux/crash_dump.h
--- linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore 2008-07-28 12:00:44.000000000 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h 2008-07-28 12:00:56.000000000 -0400
@@ -9,11 +9,7 @@
#define ELFCORE_ADDR_MAX (-1ULL)
-#ifdef CONFIG_PROC_VMCORE
extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
#define vmcore_elf_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
static inline int is_kdump_kernel(void)
{
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
_
next prev parent reply other threads:[~2008-07-28 21:18 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-26 9:25 [patch] crashdump: fix undefined reference to `elfcorehdr_addr' Ingo Molnar
2008-07-26 10:10 ` Andrew Morton
2008-07-26 10:10 ` Andrew Morton
2008-07-27 23:45 ` Simon Horman
2008-07-27 23:45 ` Simon Horman
2008-07-28 1:51 ` Simon Horman
2008-07-28 1:51 ` Simon Horman
2008-07-28 1:51 ` Simon Horman
2008-07-28 2:45 ` Simon Horman
2008-07-28 2:45 ` Simon Horman
2008-07-28 2:45 ` Simon Horman
2008-07-28 3:40 ` Simon Horman
2008-07-28 3:40 ` Simon Horman
2008-07-28 3:40 ` Simon Horman
2008-07-28 12:48 ` Ingo Molnar
2008-07-28 12:48 ` Ingo Molnar
2008-07-28 12:48 ` Ingo Molnar
2008-07-29 0:35 ` Simon Horman
2008-07-29 0:35 ` Simon Horman
2008-07-29 0:35 ` Simon Horman
2008-07-28 21:10 ` Vivek Goyal [this message]
2008-07-28 21:10 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Vivek Goyal
2008-07-28 21:10 ` Vivek Goyal
2008-07-28 21:10 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] Vivek Goyal
2008-07-28 21:11 ` [PATCH 2/5] x86: Define elfcorehdr_addr in arch dependent section Vivek Goyal
2008-07-28 21:11 ` Vivek Goyal
2008-07-28 21:11 ` Vivek Goyal
2008-07-28 21:11 ` Vivek Goyal
2008-07-28 21:13 ` [PATCH 3/5] ia64: " Vivek Goyal
2008-07-28 21:13 ` Vivek Goyal
2008-07-28 21:13 ` Vivek Goyal
2008-07-28 21:13 ` Vivek Goyal
2008-07-28 21:14 ` [PATCH 4/5] powerpc: " Vivek Goyal
2008-07-28 21:14 ` Vivek Goyal
2008-07-28 21:14 ` Vivek Goyal
2008-07-28 21:14 ` [PATCH 4/5] powerpc: Define elfcorehdr_addr in arch dependent Vivek Goyal
2008-07-28 21:15 ` [PATCH 5/5] sh: Define elfcorehdr_addr in arch dependent section Vivek Goyal
2008-07-28 21:15 ` Vivek Goyal
2008-07-28 21:15 ` Vivek Goyal
2008-07-28 21:15 ` Vivek Goyal
2008-07-29 14:18 ` Paul Mundt
2008-07-29 14:18 ` Paul Mundt
2008-07-29 14:18 ` Paul Mundt
2008-07-29 14:18 ` Paul Mundt
2008-07-29 4:42 ` [PATCH 3/5] ia64: " Simon Horman
2008-07-29 4:42 ` Simon Horman
2008-07-29 4:42 ` Simon Horman
2008-07-29 4:42 ` [PATCH 3/5] ia64: Define elfcorehdr_addr in arch dependent Simon Horman
2008-07-29 13:53 ` [PATCH 3/5] ia64: Define elfcorehdr_addr in arch dependent section Vivek Goyal
2008-07-29 13:53 ` Vivek Goyal
2008-07-29 13:53 ` Vivek Goyal
2008-07-29 13:53 ` [PATCH 3/5] ia64: Define elfcorehdr_addr in arch dependent Vivek Goyal
2008-07-31 15:29 ` [PATCH 2/5] x86: Define elfcorehdr_addr in arch dependent section Ingo Molnar
2008-07-31 15:29 ` Ingo Molnar
2008-07-31 15:29 ` Ingo Molnar
2008-07-31 15:29 ` [PATCH 2/5] x86: Define elfcorehdr_addr in arch dependent Ingo Molnar
2008-07-28 22:37 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Eric W. Biederman
2008-07-28 22:37 ` Eric W. Biederman
2008-07-28 22:37 ` Eric W. Biederman
2008-07-28 22:37 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined refe Eric W. Biederman
2008-07-28 22:47 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Eric W. Biederman
2008-07-28 22:47 ` Eric W. Biederman
2008-07-28 22:47 ` Eric W. Biederman
2008-07-28 22:47 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined refe Eric W. Biederman
2008-07-29 1:22 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Simon Horman
2008-07-29 1:22 ` Simon Horman
2008-07-29 1:22 ` Simon Horman
2008-07-29 1:22 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Simon Horman
2008-07-29 2:28 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Vivek Goyal
2008-07-29 2:28 ` Vivek Goyal
2008-07-29 2:28 ` Vivek Goyal
2008-07-29 2:28 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Vivek Goyal
2008-07-29 3:26 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Simon Horman
2008-07-29 3:26 ` Simon Horman
2008-07-29 3:26 ` Simon Horman
2008-07-29 3:26 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Simon Horman
2008-07-28 5:39 ` [patch] crashdump: fix undefined reference to `elfcorehdr_addr' Eric W. Biederman
2008-07-28 5:39 ` Eric W. Biederman
2008-07-28 5:39 ` Eric W. Biederman
2008-07-28 6:24 ` Muli Ben-Yehuda
2008-07-28 6:24 ` Muli Ben-Yehuda
2008-07-28 6:24 ` Muli Ben-Yehuda
2008-07-28 13:44 ` Vivek Goyal
2008-07-28 13:44 ` Vivek Goyal
2008-07-28 13:44 ` Vivek Goyal
2008-07-28 19:12 ` Eric W. Biederman
2008-07-28 19:12 ` Eric W. Biederman
2008-07-28 19:12 ` Eric W. Biederman
2008-07-28 13:31 ` Vivek Goyal
2008-07-28 13:31 ` Vivek Goyal
2008-07-28 13:31 ` Vivek Goyal
2008-07-29 0:33 ` Simon Horman
2008-07-29 0:33 ` Simon Horman
2008-07-29 0:33 ` Simon Horman
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=20080728211025.GA9985@redhat.com \
--to=vgoyal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=chandru@in.ibm.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=lethal@linux-sh.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=muli@il.ibm.com \
--cc=paulus@samba.org \
--cc=terry.loftin@hp.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.