x86: fix memmap=exactmap boot argument
When using kdump modifying the e820 map is yielding strange results.
For example starting with
BIOS-provided physical RAM map:
BIOS-e820:
0000000000000100 -
0000000000093400 (usable)
BIOS-e820:
0000000000093400 -
00000000000a0000 (reserved)
BIOS-e820:
0000000000100000 -
000000003fee0000 (usable)
BIOS-e820:
000000003fee0000 -
000000003fef3000 (ACPI data)
BIOS-e820:
000000003fef3000 -
000000003ff80000 (ACPI NVS)
BIOS-e820:
000000003ff80000 -
0000000040000000 (reserved)
BIOS-e820:
00000000e0000000 -
00000000f0000000 (reserved)
BIOS-e820:
00000000fec00000 -
00000000fec10000 (reserved)
BIOS-e820:
00000000fee00000 -
00000000fee01000 (reserved)
BIOS-e820:
00000000ff000000 -
0000000100000000 (reserved)
and booting with args
memmap=exactmap memmap=640K@0K memmap=5228K@16384K memmap=125188K@22252K memmap=76K#1047424K memmap=564K#1047500K
resulted in:
user-defined physical RAM map:
user:
0000000000000000 -
0000000000093400 (usable)
user:
0000000000093400 -
00000000000a0000 (reserved)
user:
0000000000100000 -
000000003fee0000 (usable)
user:
000000003fee0000 -
000000003fef3000 (ACPI data)
user:
000000003fef3000 -
000000003ff80000 (ACPI NVS)
user:
000000003ff80000 -
0000000040000000 (reserved)
user:
00000000e0000000 -
00000000f0000000 (reserved)
user:
00000000fec00000 -
00000000fec10000 (reserved)
user:
00000000fee00000 -
00000000fee01000 (reserved)
user:
00000000ff000000 -
0000000100000000 (reserved)
But should have resulted in:
user-defined physical RAM map:
user:
0000000000000000 -
00000000000a0000 (usable)
user:
0000000001000000 -
000000000151b000 (usable)
user:
00000000015bb000 -
0000000008ffc000 (usable)
user:
000000003fee0000 -
000000003ff80000 (ACPI data)
This is happening because of an improper usage of strcmp() in the
e820 parsing code. The strcmp() always returns !0 and never resets the
value for e820.nr_map and returns an incorrect user-defined map.
This patch fixes the problem.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>