Message ID | 149633761543.6229.12888040793158845755.stgit@hbathini.in.ibm.com (mailing list archive) |
---|---|
State | Accepted |
Commit | a77af552ccc9d4d54459a39f9e5f7ad307aeb4f9 |
Headers | show |
On Thu, 2017-06-01 at 17:20:38 UTC, Hari Bathini 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 5 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 > 0x0000000000001894 0x0000000000001894 0 > LOAD 0x0000000000021020 0xc000000000000000 0x0000000000000000 > 0x0000000040000000 0x0000000040000000 RWE 0 > LOAD 0x0000000040031020 0xc000000000000000 0x0000000000000000 > 0x0000000010000000 0x0000000010000000 RWE 0 > LOAD 0x0000000050040000 0xc000000010000000 0x0000000010000000 > 0x0000000050000000 0x0000000050000000 RWE 0 > LOAD 0x00000000a0040000 0xc000000060000000 0x0000000060000000 > 0x000000019ffe0000 0x000000019ffe0000 RWE 0 > > and with this change: > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > NOTE 0x0000000000010000 0x0000000000000000 0x0000000000000000 > 0x0000000000001894 0x0000000000001894 0 > LOAD 0x0000000000021020 0xc000000000000000 0x0000000000000000 > 0x0000000040000000 0x0000000040000000 RWE 0 > LOAD 0x0000000040030000 0xc000000040000000 0x0000000040000000 > 0x0000000020000000 0x0000000020000000 RWE 0 > LOAD 0x0000000060030000 0xc000000060000000 0x0000000060000000 > 0x000000019ffe0000 0x000000019ffe0000 RWE 0 > > Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> > Reviewed-by: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/a77af552ccc9d4d54459a39f9e5f7a cheers
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index 466569e..f7ba0dc 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -831,8 +831,19 @@ 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 != 0); + if (start < fw_dump.boot_memory_size) { + if (end > fw_dump.boot_memory_size) + start = fw_dump.boot_memory_size; + else + continue; + } /* add this range excluding the reserved dump area. */ fadump_exclude_reserved_area(start, end);