[patch v3 2/8] kdump: Make kimage_load_crash_segment() weak

Michael Holzheu holzheu at linux.vnet.ibm.com
Fri Aug 19 09:27:52 EDT 2011

Hello Vivek,

On Thu, 2011-08-18 at 13:15 -0400, Vivek Goyal wrote:
> On Fri, Aug 12, 2011 at 03:48:51PM +0200, Michael Holzheu wrote:
> > From: Michael Holzheu <holzheu at linux.vnet.ibm.com>
> > 
> > On s390 we do not create page tables at all for the crashkernel memory.
> > This requires a s390 specific version for kimage_load_crash_segment().
> > Therefore this patch declares this function as "__weak". The s390 version is
> > very simple. It just copies the kexec segment to real memory without using
> > page tables:
> > 
> > int kimage_load_crash_segment(struct kimage *image,
> >                               struct kexec_segment *segment)
> > {
> >         return copy_from_user_real((void *) segment->mem, segment->buf,
> >                                    segment->bufsz);
> > }
> > 
> > There are two main advantages of not creating page tables for the
> > crashkernel memory:
> > 
> > a) It saves memory. We have scenarios in mind, where crashkernel
> >    memory can be very large and saving page table space is important.
> > b) We protect the crashkernel memory from being overwritten.
> Michael,
> Thinking more about it. Can't we provide a arch specific version of
> kmap() and kunmap() so that we create temporary mappings to copy
> the pages and then these are torn off.

Isn't kmap/kunmap() used for higmem? These functions are called from
many different functions in the Linux kernel, not only for kdump. I
would assume that creating and removing mappings with these functions is
not what a caller would expect and probably would break the Linux kernel
at many other places, no?

Perhaps we can finish this discussion after my vacation. I will change
my patch series that we even do not need this patch...

So only two common code patches are remaining. I will send the common
code patches again and will ask Andrew Morton to integrate them in the
next merge window. The s390 patches will be integrated by Martin.


More information about the kexec mailing list