Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')

Vivek Goyal [off-list ref] writes:

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.

Given the current state of the code:
Acked-by: "Eric W. Biederman" <redacted>

To process a kernel crash dump we pass the kernel elfcorehdr option, so testing
to see if it was passed seems reasonable.

In general I think this method of handling the problems with kdump is
too brittle to live, but in the case of iommus we certainly need to do something
different, and unfortunately iommus were not common on x86 when the original code
was merged so we have not handled them well.

Eric

On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:

Vivek Goyal [off-list ref] writes:

quoted

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.

Given the current state of the code:
Acked-by: "Eric W. Biederman" <redacted>

To process a kernel crash dump we pass the kernel elfcorehdr option,
so testing to see if it was passed seems reasonable.

In general I think this method of handling the problems with kdump is
too brittle to live, but in the case of iommus we certainly need to do
something different, and unfortunately iommus were not common on x86
when the original code was merged so we have not handled them well.

Agreed, however these patches look like they really ought to be merged
into a single patch for the sake of bisect. As things stand, applying
the first patch will break the build on each architecture with an
architecture specific until the latter is applied.

-- 
Horms

On Tue, Jul 29, 2008 at 11:22:48AM +1000, Simon Horman wrote:

On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:

quoted

Vivek Goyal [off-list ref] writes:

quoted

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.

Given the current state of the code:
Acked-by: "Eric W. Biederman" <redacted>

To process a kernel crash dump we pass the kernel elfcorehdr option,
so testing to see if it was passed seems reasonable.

In general I think this method of handling the problems with kdump is
too brittle to live, but in the case of iommus we certainly need to do
something different, and unfortunately iommus were not common on x86
when the original code was merged so we have not handled them well.

Agreed, however these patches look like they really ought to be merged
into a single patch for the sake of bisect. As things stand, applying
the first patch will break the build on each architecture with an
architecture specific until the latter is applied.

That's a good point. I was not very sure because changes were in 
different arches and I broke the patch. At the same time changes are
really miniscule in each arch. 

So, for the sake of not breaking compilation for git-bisect, I will
generate a single patch tomorrow. (Until and unless somebody has an
objection).

Thanks
Vivek

-- 
Horms

On Mon, Jul 28, 2008 at 10:28:22PM -0400, Vivek Goyal wrote:

On Tue, Jul 29, 2008 at 11:22:48AM +1000, Simon Horman wrote:

quoted

On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote:

quoted

Vivek Goyal [off-list ref] writes:

quoted

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.

Given the current state of the code:
Acked-by: "Eric W. Biederman" <redacted>

To process a kernel crash dump we pass the kernel elfcorehdr option,
so testing to see if it was passed seems reasonable.

In general I think this method of handling the problems with kdump is
too brittle to live, but in the case of iommus we certainly need to do
something different, and unfortunately iommus were not common on x86
when the original code was merged so we have not handled them well.

Agreed, however these patches look like they really ought to be merged
into a single patch for the sake of bisect. As things stand, applying
the first patch will break the build on each architecture with an
architecture specific until the latter is applied.

That's a good point. I was not very sure because changes were in 
different arches and I broke the patch. At the same time changes are
really miniscule in each arch. 

I guessed that was why you split them up. But really the
per-arch change is very small.

So, for the sake of not breaking compilation for git-bisect, I will
generate a single patch tomorrow. (Until and unless somebody has an
objection).

For combiled patch:

Acked-by: Simon Horman <horms@verge.net.au>

-- 
Horms