On Fri, 12 May 2017 00:52:47 +0530
Hari Bathini <hbath...@linux.vnet.ibm.com> wrote:
> fadump sets up crash memory ranges to be used for creating PT_LOAD
> program headers in elfcore header. Memory chunk RMA_START through
> boot memory area size is added as the first memory range because
> firmware, at the time of crash, moves this memory chunk to different
> location specified during fadump registration making it necessary to
> create a separate program header for it with the correct offset.
> This memory chunk is skipped while setting up the remaining memory
> ranges. But currently, there is possibility that some of this memory
> may have duplicate entries like when it is hot-removed and added
> again. Ensure that no two memory ranges represent the same memory.
>
> When 10 lmbs are hot-removed and then hot-plugged before registering
> fadump, here is how the program headers in /proc/vmcore exported by
> fadump look like
>
> without this change:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000010000 0x0000000000000000
> 0x0000000000000000 0x0000000000001890 0x0000000000001890 0
> LOAD 0x0000000000021020 0xc000000000000000
> 0x0000000000000000 0x0000000080000000 0x0000000080000000 RWE 0
> LOAD 0x0000000080031020 0xc000000000000000
> 0x0000000000000000 0x0000000020000000 0x0000000020000000 RWE 0
> LOAD 0x00000000a0040000 0xc000000020000000
> 0x0000000020000000 0x0000000050000000 0x0000000050000000 RWE 0
> LOAD 0x00000000f0040000 0xc000000070000000
> 0x0000000070000000 0x0000000010000000 0x0000000010000000 RWE 0
> LOAD 0x0000000100040000 0xc000000100020000
> 0x0000000100020000 0x000000000ffe0000 0x000000000ffe0000 RWE 0
> LOAD 0x0000000110020000 0xc000000110000000
> 0x0000000110000000 0x00000000b0000000 0x00000000b0000000 RWE 0
> LOAD 0x00000001c0020000 0xc0000001c0000000
> 0x00000001c0000000 0x0000000080000000 0x0000000080000000 RWE 0
>
> and with this change:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000010000 0x0000000000000000
> 0x0000000000000000 0x0000000000001890 0x0000000000001890 0
> LOAD 0x0000000000021020 0xc000000000000000
> 0x0000000000000000 0x0000000080000000 0x0000000080000000 RWE 0
> LOAD 0x0000000080030000 0xc000000100020000
> 0x0000000100020000 0x000000000ffe0000 0x000000000ffe0000 RWE 0
> LOAD 0x0000000090010000 0xc000000110000000
> 0x0000000110000000 0x0000000060000000 0x0000000060000000 RWE 0
> LOAD 0x00000000f0010000 0xc000000170000000
> 0x0000000170000000 0x00000000d0000000 0x00000000d0000000 RWE 0
>
>
> Signed-off-by: Hari Bathini <hbath...@linux.vnet.ibm.com>
> Reviewed-by: Mahesh J Salgaonkar <mah...@linux.vnet.ibm.com>
> ---
>
> Changes since v1:
> * Changelog updated based on data from latest kerenl.
> * Updated comment with the assumption involved.
>
>
> arch/powerpc/kernel/fadump.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c
> b/arch/powerpc/kernel/fadump.c index 466569e..e4e1a14 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -831,8 +831,18 @@ static void
> fadump_setup_crash_memory_ranges(void) for_each_memblock(memory, reg)
> { start = (unsigned long long)reg->base;
> end = start + (unsigned long long)reg->size;
> - if (start == RMA_START && end >=
> fw_dump.boot_memory_size)
> - start = fw_dump.boot_memory_size;
> +
> + /*
> + * skip the first memory chunk that is already added
> (RMA_START
> + * through boot_memory_size). This logic needs a
> relook if and
> + * when RMA_START changes to a non-zero value.
> + */
BUILD_BUG_ON(RMA_START)?
Thanks
Michal
