kdump: Patch series for s390 support (version 3)

From: Michael Holzheu <[email protected]>

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.

Quoted 15 lines · Michael Holzheu

From: Michael Holzheu <[email protected]>

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);
}

Quoted 6 lines

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.

Hello Vivek,

Quoted 23 lines · Vivek Goyal

Quoted 15 lines · Michael Holzheu

From: Michael Holzheu <[email protected]>

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);
}

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 11 lines

Quoted 5 lines

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?

[CCing linux-mm]

Yes it is being used for highmem pages. If arch has not defined kmap() then generic definition is just returning page_address(page), expecting that page will be mapped.

I was wondering that what will be broken if arch decides to extend this to create temporary mappings for pages which are not HIGHMEM but do not have any mapping. (Like this special case of s390).

I guess memory management guys can give a better answer here. As a layman, kmap() seems to be the way to get a kernel mapping for any page frame and if one is not already there, then arch might create one on the fly, like we do for HIGHMEM pages. So the question is can be extend this to also cover pages which are not highmem but do not have any mappings on s390.

Quoted 1 line

Quoted 2 lines

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

So how are you planning to get rid of this patch without modifying kmap(), kunmap() implementation for s390?

Quoted 3 lines

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.

I am fine with merge of other 2 common patches. Once you repost the series, I will ack those.

Quoted 32 lines · Michael Holzheu

Hello Vivek,

Quoted 23 lines · Vivek Goyal

Quoted 15 lines · Michael Holzheu

From: Michael Holzheu <[email protected]>

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);
}

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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?

[CCing linux-mm]

Yes it is being used for highmem pages. If arch has not defined kmap() then generic definition is just returning page_address(page), expecting that page will be mapped.

I was wondering that what will be broken if arch decides to extend this to create temporary mappings for pages which are not HIGHMEM but do not have any mapping. (Like this special case of s390).

I guess memory management guys can give a better answer here. As a layman, kmap() seems to be the way to get a kernel mapping for any page frame and if one is not already there, then arch might create one on the fly, like we do for HIGHMEM pages. So the question is can be extend this to also cover pages which are not highmem but do not have any mappings on s390.

Quoted 49 lines · On Fri, 19 Aug 2011 09:48:36 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 32 lines · Michael Holzheu

Hello Vivek,

Quoted 23 lines · Vivek Goyal

Quoted 15 lines · Michael Holzheu

From: Michael Holzheu <[email protected]>

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);
}

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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?

[CCing linux-mm]

Yes it is being used for highmem pages. If arch has not defined kmap() then generic definition is just returning page_address(page), expecting that page will be mapped.

I was wondering that what will be broken if arch decides to extend this to create temporary mappings for pages which are not HIGHMEM but do not have any mapping. (Like this special case of s390).

Quoted 6 lines

I guess memory management guys can give a better answer here. As a layman, kmap() seems to be the way to get a kernel mapping for any page frame and if one is not already there, then arch might create one on the fly, like we do for HIGHMEM pages. So the question is can be extend this to also cover pages which are not highmem but do not have any mappings on s390.

Imho it would be wrong to misuse kmap/kunmap to get around a minor problem with the memory for the crash kernel. These functions are used to provide accessibility to highmem pages in the kernel address space. The highmem area is "normal" memory with corresponding struct page elements (the functions do take a struct page * as argument after all). They are not usable to map arbitrary page frames.

And we definitely don't want to make the memory management any slower by defining non-trivial kmap/kunmap functions.

Quoted 59 lines · Martin Schwidefsky

Quoted 49 lines · On Fri, 19 Aug 2011 09:48:36 -0400 Vivek Goyal <[email protected]> wrote:

Quoted 32 lines · Michael Holzheu

Hello Vivek,

Quoted 23 lines · Vivek Goyal

Quoted 15 lines · Michael Holzheu

From: Michael Holzheu <[email protected]>

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);
}

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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?

[CCing linux-mm]

Yes it is being used for highmem pages. If arch has not defined kmap() then generic definition is just returning page_address(page), expecting that page will be mapped.

I was wondering that what will be broken if arch decides to extend this to create temporary mappings for pages which are not HIGHMEM but do not have any mapping. (Like this special case of s390).

Quoted 6 lines

I guess memory management guys can give a better answer here. As a layman, kmap() seems to be the way to get a kernel mapping for any page frame and if one is not already there, then arch might create one on the fly, like we do for HIGHMEM pages. So the question is can be extend this to also cover pages which are not highmem but do not have any mappings on s390.

Quoted 6 lines

Imho it would be wrong to misuse kmap/kunmap to get around a minor problem with the memory for the crash kernel. These functions are used to provide accessibility to highmem pages in the kernel address space. The highmem area is "normal" memory with corresponding struct page elements (the functions do take a struct page * as argument after all). They are not usable to map arbitrary page frames.

Same is the case with crashkernel memory in s390 where these are normal pages, just that these are not mapped in linearly mapped region.

The only exception to highmem pages is that linearly mapped region is not big enough in certain arches, so we left them unmapped.

Quoted 3 lines

And we definitely don't want to make the memory management any slower by defining non-trivial kmap/kunmap functions.

if we continue to return page_address() and only go into else loop if page is not mapped, then there should not be any slow down for exisitng cases where memory is mapped?

Anyway, this was just a thought. I am not too particular about it and michael has agreed to get rid of code which was removing mappings for crashkernel area. So for the time we don't need above.

From: Michael Holzheu <[email protected]>

Currently only the address of the pre-allocated ELF header is passed with the elfcorehdr= kernel parameter. In order to reserve memory for the header in the 2nd kernel also the size is required. Current kdump architecture backends use different methods to do that, e.g. x86 uses the memmap= kernel parameter. On s390 there is no easy way to transfer this information. Therefore the elfcorehdr kernel parameter is extended to also pass the size. This now can also be used as standard mechanism by all future kdump architecture backends.

Quoted 10 lines · Michael Holzheu

From: Michael Holzheu <[email protected]>

Currently only the address of the pre-allocated ELF header is passed with the elfcorehdr= kernel parameter. In order to reserve memory for the header in the 2nd kernel also the size is required. Current kdump architecture backends use different methods to do that, e.g. x86 uses the memmap= kernel parameter. On s390 there is no easy way to transfer this information. Therefore the elfcorehdr kernel parameter is extended to also pass the size. This now can also be used as standard mechanism by all future kdump architecture backends.

Michael,

This version looks much better. A quick question. Who parses this elfcorehdr= parameter in s390 and how do we make sure these headers are not overwritten.

Hello Vivek,

Quoted 12 lines · Vivek Goyal

Quoted 10 lines · Michael Holzheu

From: Michael Holzheu <[email protected]>

Currently only the address of the pre-allocated ELF header is passed with the elfcorehdr= kernel parameter. In order to reserve memory for the header in the 2nd kernel also the size is required. Current kdump architecture backends use different methods to do that, e.g. x86 uses the memmap= kernel parameter. On s390 there is no easy way to transfer this information. Therefore the elfcorehdr kernel parameter is extended to also pass the size. This now can also be used as standard mechanism by all future kdump architecture backends.

Quoted 5 lines

Michael,

This version looks much better. A quick question. Who parses this elfcorehdr= parameter in s390 and how do we make sure these headers are not overwritten.

The parameter is parsed in common code (kernel/crash_dump.c) in early_param("elfcorehdr", setup_elfcorehdr), as it is already currently the case.

We use address and size of the ELF core header to reserve the header memory in setup.c (see patch #8):

(quoted diff) +5 -0

+#ifdef CONFIG_CRASH_DUMP
+       if (is_kdump_kernel())
+               reserve_bootmem(elfcorehdr_addr - OLDMEM_BASE,
+                               PAGE_ALIGN(elfcorehdr_size), BOOTMEM_DEFAULT);
+#endif

Does that answer your question?

Quoted 13 lines

The parameter is parsed in common code (kernel/crash_dump.c) in early_param("elfcorehdr", setup_elfcorehdr), as it is already currently the case.

We use address and size of the ELF core header to reserve the header memory in setup.c (see patch #8):

(quoted diff) +5 -0

+#ifdef CONFIG_CRASH_DUMP
+       if (is_kdump_kernel())
+               reserve_bootmem(elfcorehdr_addr - OLDMEM_BASE,
+                               PAGE_ALIGN(elfcorehdr_size), BOOTMEM_DEFAULT);
+#endif

Quoted 1 line

Does that answer your question?

Yes it does. Thanks.

It brings up few more questions about rest of the memory mangement.

So kdump kernel is loaded in reserved area but does not run from there. It reloads itself into lower memory areas and swaps the contents of lower memory with reserved memory? If yes, how does it, kernel or purgatory?

How does kernel come to know about how much memory is to be swapped

and how do you bound the memory usage of second kernel so that it does not try to use other memory which has not been swapped into reserved area.