Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI
regions being no longer mapped as NOMAP
by Bhupesh Sharma
On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
<ard.biesheuvel(a)linaro.org> wrote:
> On 19 December 2017 at 07:09, AKASHI Takahiro
> <takahiro.akashi(a)linaro.org> wrote:
>> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
>>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
>>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
>>> > > <takahiro.akashi(a)linaro.org> wrote:
>>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
>>> > > >> <takahiro.akashi(a)linaro.org> wrote:
>>> > > >> > Bhupesh, Ard,
>>> > > >> >
>>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>>> > > >> >> Hi Ard, Akashi
>>> > > >> >>
>>> > > >> > (snip)
>>> > > >> >
>>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>>> > > >> >> identify its own usable memory and exclude, at its boot time, any
>>> > > >> >> other memory areas that are part of the panicked kernel's memory.
>>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>>> > > >> >> , for details)
>>> > > >> >
>>> > > >> > Right.
>>> > > >> >
>>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>>> > > >> >> with the crashkernel memory range:
>>> > > >> >>
>>> > > >> >> /* add linux,usable-memory-range */
>>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>>> > > >> >> address_cells, size_cells);
>>> > > >> >>
>>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/ke...
>>> > > >> >> , for details)
>>> > > >> >>
>>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>>> > > >> >> they are marked as System RAM or as RESERVED. As,
>>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
>>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>>> > > >> >>
>>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
>>> > > >> >> ACPI memory and crashes while trying to access the same:
>>> > > >> >>
>>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>>> > > >> >> -r`.img --reuse-cmdline -d
>>> > > >> >>
>>> > > >> >> [snip..]
>>> > > >> >>
>>> > > >> >> Reserved memory range
>>> > > >> >> 000000000e800000-000000002e7fffff (0)
>>> > > >> >>
>>> > > >> >> Coredump memory ranges
>>> > > >> >> 0000000000000000-000000000e7fffff (0)
>>> > > >> >> 000000002e800000-000000003961ffff (0)
>>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
>>> > > >> >> 000000003ed60000-000000003fbfffff (0)
>>> > > >> >> 0000001040000000-0000001ffbffffff (0)
>>> > > >> >> 0000002000000000-0000002ffbffffff (0)
>>> > > >> >> 0000009000000000-0000009ffbffffff (0)
>>> > > >> >> 000000a000000000-000000affbffffff (0)
>>> > > >> >>
>>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>>> > > >> >> memory cap'ing passed to the crash kernel inside
>>> > > >> >> 'arch/arm64/mm/init.c' (see below):
>>> > > >> >>
>>> > > >> >> static void __init fdt_enforce_memory_region(void)
>>> > > >> >> {
>>> > > >> >> struct memblock_region reg = {
>>> > > >> >> .size = 0,
>>> > > >> >> };
>>> > > >> >>
>>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>>> > > >> >>
>>> > > >> >> if (reg.size)
>>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>>> > > >> >> comment this out */
>>> > > >> >> }
>>> > > >> >
>>> > > >> > Please just don't do that. It can cause a fatal damage on
>>> > > >> > memory contents of the *crashed* kernel.
>>> > > >> >
>>> > > >> >> 5). Both the above temporary solutions fix the problem.
>>> > > >> >>
>>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
>>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>>> > > >> >> fail.
>>> > > >> >>
>>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>>> > > >> >> dt node 'linux,usable-memory-range'
>>> > > >> >
>>> > > >> > I still don't understand why we need to carry over the information
>>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>>> > > >> > such regions are free to be reused by the kernel after some point of
>>> > > >> > initialization. Why does crash dump kernel need to know about them?
>>> > > >> >
>>> > > >>
>>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
>>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
>>> > > >> kernel, those regions needs to be preserved, which is why they are
>>> > > >> memblock_reserve()'d now.
>>> > > >
>>> > > > For my better understandings, who is actually accessing such regions
>>> > > > during boot time, uefi itself or efistub?
>>> > > >
>>> > >
>>> > > No, only the kernel. This is where the ACPI tables are stored. For
>>> > > instance, on QEMU we have
>>> > >
>>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>>> > > 01000013)
>>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>>> > > BXPC 00000001)
>>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>>> > > BXPC 00000001)
>>> > >
>>> > > covered by
>>> > >
>>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>>> > > ...
>>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>>> >
>>> > OK. I mistakenly understood those regions could be freed after exiting
>>> > UEFI boot services.
>>> >
>>> > >
>>> > > >> So it seems that kexec does not honour the memblock_reserve() table
>>> > > >> when booting the next kernel.
>>> > > >
>>> > > > not really.
>>> > > >
>>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
>>> > > >> > on crash dump kernel?)
>>> > > >> >
>>> > > >>
>>> > > >> I don't think so. And the change to the handling of ACPI reclaim
>>> > > >> regions only revealed the bug, not created it (given that other
>>> > > >> memblock_reserve regions may be affected as well)
>>> > > >
>>> > > > As whether we should honor such reserved regions over kexec'ing
>>> > > > depends on each one's specific nature, we will have to take care one-by-one.
>>> > > > As a matter of fact, no information about "reserved" memblocks is
>>> > > > exposed to user space (via proc/iomem).
>>> > > >
>>> > >
>>> > > That is why I suggested (somewhere in this thread?) to not expose them
>>> > > as 'System RAM'. Do you think that could solve this?
>>> >
>>> > Memblock-reserv'ing them is necessary to prevent their corruption and
>>> > marking them under another name in /proc/iomem would also be good in order
>>> > not to allocate them as part of crash kernel's memory.
>>> >
>>> > But I'm not still convinced that we should export them in useable-
>>> > memory-range to crash dump kernel. They will be accessed through
>>> > acpi_os_map_memory() and so won't be required to be part of system ram
>>> > (or memblocks), I guess.
>>> > -> Bhupesh?
>>>
>>> I forgot how arm64 kernel retrieve the memory ranges and initialize
>>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
>>> the memory according to the efi memmap? For kdump kernel anything other
>>> than usable memory (which is from the dt node instead) should be
>>> reinitialized according to efi passed info, no?
>>
>> All the regions exported in efi memmap will be added to memblock.memory
>> in (u)efi_init() and then trimmed down to the exact range specified as
>> usable-memory-range by fdt_enforce_memory_region().
>>
>> Now I noticed that the current fdt_enforce_memory_region() may not work well
>> with multiple entries in usable-memory-range.
>>
>
> In any case, the root of the problem is that memory regions lose their
> 'memory' annotation due to the way the memory map is mangled before
> being supplied to the kexec kernel.
>
> Would it be possible to classify all memory that we want to hide from
> the kexec kernel as NOMAP instead? That way, it will not be mapped
> implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
> so this seems to be the most appropriate way to deal with the host
> kernel's memory contents.
Hmm. wouldn't appending the acpi reclaim regions to
'linux,usable-memory-range' in the dtb being passed to the crashkernel
be better? Because its indirectly achieving a similar objective
(although may be a subset of all System RAM regions on the primary
kernel's memory).
I am not aware of the background about the current kexec-tools
implementation where we add only the crashkernel range to the dtb
being passed to the crashkernel.
Probably Akashi can answer better, as to how we arrived at this design
approach and why we didn't want to expose all System RAM regions (i.e.
! NOMPAP regions) to the crashkernel.
I am suspecting that some issues were seen/meet when the System RAM (!
NOMAP regions) were exposed to the crashkernel, and that's why we
finalized on this design approach, but this is something which is just
my guess.
Regards,
Bhupesh
>>> >
>>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>>> > via a kernel command line parameter, "memmap=".
>>>
>>> memmap= is only used in old kexec-tools, now we are passing them via
>>> e820 table.
>>
>> Thanks. I remember that you have explained it before.
>>
>> -Takahiro AKASHI
>>
>>> [snip]
>>>
>>> Thanks
>>> Dave
5 years, 11 months
Re: arm64 crashkernel fails to boot on acpi-only machines due to
ACPI regions being no longer mapped as NOMAP
by Dave Young
On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> > On 13 December 2017 at 12:16, AKASHI Takahiro
> > <takahiro.akashi(a)linaro.org> wrote:
> > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> > >> <takahiro.akashi(a)linaro.org> wrote:
> > >> > Bhupesh, Ard,
> > >> >
> > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> > >> >> Hi Ard, Akashi
> > >> >>
> > >> > (snip)
> > >> >
> > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> > >> >> identify its own usable memory and exclude, at its boot time, any
> > >> >> other memory areas that are part of the panicked kernel's memory.
> > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> > >> >> , for details)
> > >> >
> > >> > Right.
> > >> >
> > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> > >> >> with the crashkernel memory range:
> > >> >>
> > >> >> /* add linux,usable-memory-range */
> > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> > >> >> address_cells, size_cells);
> > >> >>
> > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/ke...
> > >> >> , for details)
> > >> >>
> > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> > >> >> they are marked as System RAM or as RESERVED. As,
> > >> >> 'linux,usable-memory-range' dt node is patched up only with
> > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> > >> >>
> > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> > >> >> ACPI memory and crashes while trying to access the same:
> > >> >>
> > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > >> >> -r`.img --reuse-cmdline -d
> > >> >>
> > >> >> [snip..]
> > >> >>
> > >> >> Reserved memory range
> > >> >> 000000000e800000-000000002e7fffff (0)
> > >> >>
> > >> >> Coredump memory ranges
> > >> >> 0000000000000000-000000000e7fffff (0)
> > >> >> 000000002e800000-000000003961ffff (0)
> > >> >> 0000000039d40000-000000003ed2ffff (0)
> > >> >> 000000003ed60000-000000003fbfffff (0)
> > >> >> 0000001040000000-0000001ffbffffff (0)
> > >> >> 0000002000000000-0000002ffbffffff (0)
> > >> >> 0000009000000000-0000009ffbffffff (0)
> > >> >> 000000a000000000-000000affbffffff (0)
> > >> >>
> > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> > >> >> memory cap'ing passed to the crash kernel inside
> > >> >> 'arch/arm64/mm/init.c' (see below):
> > >> >>
> > >> >> static void __init fdt_enforce_memory_region(void)
> > >> >> {
> > >> >> struct memblock_region reg = {
> > >> >> .size = 0,
> > >> >> };
> > >> >>
> > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> > >> >>
> > >> >> if (reg.size)
> > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> > >> >> comment this out */
> > >> >> }
> > >> >
> > >> > Please just don't do that. It can cause a fatal damage on
> > >> > memory contents of the *crashed* kernel.
> > >> >
> > >> >> 5). Both the above temporary solutions fix the problem.
> > >> >>
> > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> > >> >> fail.
> > >> >>
> > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> > >> >> dt node 'linux,usable-memory-range'
> > >> >
> > >> > I still don't understand why we need to carry over the information
> > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> > >> > such regions are free to be reused by the kernel after some point of
> > >> > initialization. Why does crash dump kernel need to know about them?
> > >> >
> > >>
> > >> Not really. According to the UEFI spec, they can be reclaimed after
> > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> > >> no longer needs them. Of course, in order to be able to boot a kexec
> > >> kernel, those regions needs to be preserved, which is why they are
> > >> memblock_reserve()'d now.
> > >
> > > For my better understandings, who is actually accessing such regions
> > > during boot time, uefi itself or efistub?
> > >
> >
> > No, only the kernel. This is where the ACPI tables are stored. For
> > instance, on QEMU we have
> >
> > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> > 01000013)
> > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> > BXPC 00000001)
> > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> > BXPC 00000001)
> > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> > BXPC 00000001)
> > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> > BXPC 00000001)
> > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> > BXPC 00000001)
> > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> > BXPC 00000001)
> > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> > BXPC 00000001)
> >
> > covered by
> >
> > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> > ...
> > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>
> OK. I mistakenly understood those regions could be freed after exiting
> UEFI boot services.
>
> >
> > >> So it seems that kexec does not honour the memblock_reserve() table
> > >> when booting the next kernel.
> > >
> > > not really.
> > >
> > >> > (In other words, can or should we skip some part of ACPI-related init code
> > >> > on crash dump kernel?)
> > >> >
> > >>
> > >> I don't think so. And the change to the handling of ACPI reclaim
> > >> regions only revealed the bug, not created it (given that other
> > >> memblock_reserve regions may be affected as well)
> > >
> > > As whether we should honor such reserved regions over kexec'ing
> > > depends on each one's specific nature, we will have to take care one-by-one.
> > > As a matter of fact, no information about "reserved" memblocks is
> > > exposed to user space (via proc/iomem).
> > >
> >
> > That is why I suggested (somewhere in this thread?) to not expose them
> > as 'System RAM'. Do you think that could solve this?
>
> Memblock-reserv'ing them is necessary to prevent their corruption and
> marking them under another name in /proc/iomem would also be good in order
> not to allocate them as part of crash kernel's memory.
>
> But I'm not still convinced that we should export them in useable-
> memory-range to crash dump kernel. They will be accessed through
> acpi_os_map_memory() and so won't be required to be part of system ram
> (or memblocks), I guess.
> -> Bhupesh?
I forgot how arm64 kernel retrieve the memory ranges and initialize
them. If no "e820" like interfaces shouldn't kernel reinitialize all
the memory according to the efi memmap? For kdump kernel anything other
than usable memory (which is from the dt node instead) should be
reinitialized according to efi passed info, no?
>
> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> via a kernel command line parameter, "memmap=".
memmap= is only used in old kexec-tools, now we are passing them via
e820 table.
[snip]
Thanks
Dave
5 years, 11 months
Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI
regions being no longer mapped as NOMAP
by Bhupesh Sharma
On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
<ard.biesheuvel(a)linaro.org> wrote:
> On 15 December 2017 at 09:59, AKASHI Takahiro
> <takahiro.akashi(a)linaro.org> wrote:
>> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>>> On 13 December 2017 at 12:16, AKASHI Takahiro
>>> <takahiro.akashi(a)linaro.org> wrote:
>>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
>>> >> <takahiro.akashi(a)linaro.org> wrote:
>>> >> > Bhupesh, Ard,
>>> >> >
>>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>>> >> >> Hi Ard, Akashi
>>> >> >>
>>> >> > (snip)
>>> >> >
>>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>>> >> >> identify its own usable memory and exclude, at its boot time, any
>>> >> >> other memory areas that are part of the panicked kernel's memory.
>>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>>> >> >> , for details)
>>> >> >
>>> >> > Right.
>>> >> >
>>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>>> >> >> with the crashkernel memory range:
>>> >> >>
>>> >> >> /* add linux,usable-memory-range */
>>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>>> >> >> address_cells, size_cells);
>>> >> >>
>>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/ke...
>>> >> >> , for details)
>>> >> >>
>>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>>> >> >> they are marked as System RAM or as RESERVED. As,
>>> >> >> 'linux,usable-memory-range' dt node is patched up only with
>>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>>> >> >>
>>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
>>> >> >> ACPI memory and crashes while trying to access the same:
>>> >> >>
>>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>>> >> >> -r`.img --reuse-cmdline -d
>>> >> >>
>>> >> >> [snip..]
>>> >> >>
>>> >> >> Reserved memory range
>>> >> >> 000000000e800000-000000002e7fffff (0)
>>> >> >>
>>> >> >> Coredump memory ranges
>>> >> >> 0000000000000000-000000000e7fffff (0)
>>> >> >> 000000002e800000-000000003961ffff (0)
>>> >> >> 0000000039d40000-000000003ed2ffff (0)
>>> >> >> 000000003ed60000-000000003fbfffff (0)
>>> >> >> 0000001040000000-0000001ffbffffff (0)
>>> >> >> 0000002000000000-0000002ffbffffff (0)
>>> >> >> 0000009000000000-0000009ffbffffff (0)
>>> >> >> 000000a000000000-000000affbffffff (0)
>>> >> >>
>>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>>> >> >> memory cap'ing passed to the crash kernel inside
>>> >> >> 'arch/arm64/mm/init.c' (see below):
>>> >> >>
>>> >> >> static void __init fdt_enforce_memory_region(void)
>>> >> >> {
>>> >> >> struct memblock_region reg = {
>>> >> >> .size = 0,
>>> >> >> };
>>> >> >>
>>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>>> >> >>
>>> >> >> if (reg.size)
>>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>>> >> >> comment this out */
>>> >> >> }
>>> >> >
>>> >> > Please just don't do that. It can cause a fatal damage on
>>> >> > memory contents of the *crashed* kernel.
>>> >> >
>>> >> >> 5). Both the above temporary solutions fix the problem.
>>> >> >>
>>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
>>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>>> >> >> fail.
>>> >> >>
>>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>>> >> >> dt node 'linux,usable-memory-range'
>>> >> >
>>> >> > I still don't understand why we need to carry over the information
>>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>>> >> > such regions are free to be reused by the kernel after some point of
>>> >> > initialization. Why does crash dump kernel need to know about them?
>>> >> >
>>> >>
>>> >> Not really. According to the UEFI spec, they can be reclaimed after
>>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>>> >> no longer needs them. Of course, in order to be able to boot a kexec
>>> >> kernel, those regions needs to be preserved, which is why they are
>>> >> memblock_reserve()'d now.
>>> >
>>> > For my better understandings, who is actually accessing such regions
>>> > during boot time, uefi itself or efistub?
>>> >
>>>
>>> No, only the kernel. This is where the ACPI tables are stored. For
>>> instance, on QEMU we have
>>>
>>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>>> 01000013)
>>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>>> BXPC 00000001)
>>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>>> BXPC 00000001)
>>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>>> BXPC 00000001)
>>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>>> BXPC 00000001)
>>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>>> BXPC 00000001)
>>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>>> BXPC 00000001)
>>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>>> BXPC 00000001)
>>>
>>> covered by
>>>
>>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>>> ...
>>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>>
>> OK. I mistakenly understood those regions could be freed after exiting
>> UEFI boot services.
>>
>>>
>>> >> So it seems that kexec does not honour the memblock_reserve() table
>>> >> when booting the next kernel.
>>> >
>>> > not really.
>>> >
>>> >> > (In other words, can or should we skip some part of ACPI-related init code
>>> >> > on crash dump kernel?)
>>> >> >
>>> >>
>>> >> I don't think so. And the change to the handling of ACPI reclaim
>>> >> regions only revealed the bug, not created it (given that other
>>> >> memblock_reserve regions may be affected as well)
>>> >
>>> > As whether we should honor such reserved regions over kexec'ing
>>> > depends on each one's specific nature, we will have to take care one-by-one.
>>> > As a matter of fact, no information about "reserved" memblocks is
>>> > exposed to user space (via proc/iomem).
>>> >
>>>
>>> That is why I suggested (somewhere in this thread?) to not expose them
>>> as 'System RAM'. Do you think that could solve this?
>>
>> Memblock-reserv'ing them is necessary to prevent their corruption and
>> marking them under another name in /proc/iomem would also be good in order
>> not to allocate them as part of crash kernel's memory.
>>
>
> I agree. However, this may not be entirely trivial, since iterating
> over the memblock_reserved table and creating iomem entries may result
> in collisions.
I found a method (using the patch I shared earlier in this thread) to mark these
entries as 'ACPI reclaim memory' ranges rather than System RAM or
reserved regions.
>> But I'm not still convinced that we should export them in useable-
>> memory-range to crash dump kernel. They will be accessed through
>> acpi_os_map_memory() and so won't be required to be part of system ram
>> (or memblocks), I guess.
>
> Agreed. They will be covered by the linear mapping in the boot kernel,
> and be mapped explicitly via ioremap_cache() in the kexec kernel,
> which is exactly what we want in this case.
Now this is what is confusing me. I don't see the above happening.
I see that the primary kernel boots up and adds the ACPI regions via:
acpi_os_ioremap
-> ioremap_cache
But during the crashkernel boot, ''acpi_os_ioremap' calls
'ioremap' for the ACPI Reclaim Memory regions and not the _cache
variant.
And it fails while accessing the ACPI tables:
[ 0.039205] ACPI: Core revision 20170728
pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
[ 0.095098] Internal error: Oops: 96000021 [#1] SMP
[ 0.100022] Modules linked in:
[ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
[ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
[ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
[ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
[ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
pstate: 60000045
[ 0.132647] sp : ffff000008ccfb40
[ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
[ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
[ 0.146718] x25: 000000000000001b x24: 0000000000000001
[ 0.152083] x23: 0000000000000001 x22: ffff000009710027
[ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
[ 0.162812] x19: 000000000000001b x18: 0000000000000005
[ 0.168176] x17: 0000000000000000 x16: 0000000000000000
[ 0.173541] x15: 0000000000000000 x14: 000000000000038e
[ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
[ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
[ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
[ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
[ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
[ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
[ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
[ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
[ 0.223224] Call trace:
[ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
[ 0.232194] fa00: 0000000000000000 ffff000009710027
ffff0000095e3980 ffff000008ccfbe0
[ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
ffff000008ccfc50 0000000000000000
[ 0.248018] fa40: ffff8000126d0140 000000000000005f
00000000ffffff76 0000000000000006
[ 0.255931] fa60: ffffffffffffffff ffffffff00000000
000000000000038e 0000000000000000
[ 0.263843] fa80: 0000000000000000 0000000000000000
0000000000000005 000000000000001b
[ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
ffff000009710027 0000000000000001
[ 0.279667] fac0: 0000000000000001 000000000000001b
0000000000000000 ffff0000088be820
[ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
ffff00000849b4f8 ffff000008ccfb40
[ 0.295491] fb00: ffff0000084a6764 0000000060000045
ffff000008ccfb40 ffff000008260a18
[ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
ffff000008ccfb40 ffff0000084a6764
[ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
[ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
[ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
[ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
[ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
[ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
[ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
[ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
[ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
[ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
[ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
[ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
[ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
[ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
[ 0.394500] ---[ end trace c46ed37f9651c58e ]---
[ 0.399160] Kernel panic - not syncing: Fatal exception
[ 0.404437] Rebooting in 10 seconds.
So, I think the linear mapping done by the primary kernel does not
make these accessible in the crash kernel directly.
Any pointers?
Regards,
Bhupesh
>> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> via a kernel command line parameter, "memmap=".
>>
5 years, 11 months
Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI
regions being no longer mapped as NOMAP
by Bhupesh Sharma
Hi Ard, Akashi
On Mon, Dec 4, 2017 at 7:32 PM, Ard Biesheuvel
<ard.biesheuvel(a)linaro.org> wrote:
> On 26 November 2017 at 08:29, Bhupesh SHARMA <bhupesh.linux(a)gmail.com> wrote:
>> Hi Akashi,
>>
>> On Thu, Nov 16, 2017 at 12:30 PM, AKASHI Takahiro
>> <takahiro.akashi(a)linaro.org> wrote:
>>> Bhupesh,
>>>
>>> On Wed, Nov 15, 2017 at 04:28:55PM +0530, Bhupesh Sharma wrote:
>>>>
>>> (snip)
>>>
>>>> # dmesg | grep -B 2 -i "ACPI reclaim"
>>>> [ 0.000000] efi: 0x000039670000-0x0000396bffff [Runtime Code |RUN| |
>>>> | | | | | |WB|WT|WC|UC]
>>>> [ 0.000000] efi: 0x0000396c0000-0x00003970ffff [Boot Code | | | |
>>>> | | | | |WB|WT|WC|UC]
>>>> [ 0.000000] efi: 0x000039710000-0x00003975ffff [ACPI Reclaim Memory|
>>>> | | | | | | | |WB|WT|WC|UC]
>>>>
>>>> 2. Now, I am not sure which kernel layer does the following changes (I am
>>>> still trying to dig it out more), but I see that the 'Boot Code' and ACPI
>>>> DSDT table regions are somehow merged into one memblock_region and appear as
>>>> range '396c0000-3975ffff' in the '/proc/iomem' interface:
>>>>
>>>> # cat /proc/iomem | grep -A 2 -B 2 39
>>>> 00000000-3961ffff : System RAM
>>>> 00080000-00b6ffff : Kernel code
>>>> 00cb0000-0167ffff : Kernel data
>>>> 0e800000-2e7fffff : Crash kernel
>>>> 39620000-396bffff : reserved
>>>> 396c0000-3975ffff : System RAM
>>>> 39760000-3976ffff : reserved
>>>> 39770000-397affff : reserved
>>>> 397b0000-3989ffff : reserved
>>>> 398a0000-398bffff : reserved
>>>> 398c0000-39d3ffff : reserved
>>>> 39d40000-3ed2ffff : System RAM
>>>>
>>> (snip)
>>>>
>>>> So, I am looking at what could be causing the 'Boot Code' and 'ACPI DSDT
>>>> table' ranges to be merged into a single region at
>>>> '0x0000396c0000-0x00003970ffff' which cannot be marked as RESERVED using
>>>> 'memblock_is_reserved'.
>>>
>>> Simple:) The short answer is that memblock_add() does.
>>>
>>> The long answer:
>>> First, please note that memblock maintains two type of regions list,
>>> "memory" and "reserved".
>>>
>>> efi_init()
>>> reserve_regions()
>>> early_init_dt_add_memory_arch()
>>> memblock_add()
>>> memblock_add_range(memblock.memory)
>>>
>>> The memory regions described in efi.memmap are added to "memory" list
>>> with all the neighboring regions being merged into ones,
>>> in this case, "Runtime Code", "Boot Code", "ACPI Reclaim Memory" and others.
>>>
>>> The secret here is that "Runtime Code" is also marked with "NOMAP" flag in
>>> reserve_regions(), which creates an isolated region since it now has
>>> a different attribute.
>>> Consequently only "Boot Code" and "ACPI Reclaim Memory" are
>>> unified.
>>>
>>> Look at request_standard_resources(). It handles only "memory" list,
>>> and doesn't care about whether any arbitrary part of memory is in
>>> "reserved" list or not.
>>
>> Thanks for the pointers. Now I did some experiments and traversed the
>> whole memblock path and I see
>> how these two regions get merged into a single region which is later
>> on recognized by
>> 'request_standard_resources()' as a System RAM region rather than a
>> RESERVED region.
>>
>> I recently reproduced this on a APM mustang with latest kernel as well
>> when acpi is used to boot the machine, which makes me believe that
>> this is a generic issue for arm64 machines with the 4.14 kernel and if
>> they use acpi=force as the boot method.
>>
>> I am not sure, if a fix/or hack would be suitable for all underlying
>> arm64 machines, but I am trying one on the arm64 machines I have to
>> see if it fixes the issue.
>>
>> @Ard:
>>
>> Hi Ard,
>>
>> I think to create and test a clean solution for all arm64 boards it
>> will take some time, in the meantime should we consider reverting the
>> commit [1] to make sure that acpi enabled arm64 machines can boot with
>> 4.14?
>>
>> Please let me know your opinion.
>>
>> [1] f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a (efi/arm: Don't mark
>> ACPI reclaim memory as MEMBLOCK_NOMAP)
>>
>
> I don't think that is really going to help tbh.
>
> ACPI reclaim regions are not the only regions that are
> memblock_reserve()d and need to be reserved by the incoming kernel as
> well. So as far as I can tell, this is a symptom of an underlying
> issue that we will need to solve, and reverting the code that exposed
> it will not make the bug go away.
>
Looking deeper into the issue, since the arm64 kexec-tools uses the
'linux,usable-memory-range' dt property to allow crash dump kernel to
identify its own usable memory and exclude, at its boot time, any
other memory areas that are part of the panicked kernel's memory.
(see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
, for details)
1). Now when 'kexec -p' is executed, this node is patched up only
with the crashkernel memory range:
/* add linux,usable-memory-range */
nodeoffset = fdt_path_offset(new_buf, "/chosen");
result = fdt_setprop_range(new_buf, nodeoffset,
PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
address_cells, size_cells);
(see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/ke...
, for details)
2). This excludes the ACPI reclaim regions irrespective of whether
they are marked as System RAM or as RESERVED. As,
'linux,usable-memory-range' dt node is patched up only with
'crash_reserved_mem' and not 'system_memory_ranges'
3). As a result when the crashkernel boots up it doesn't find this
ACPI memory and crashes while trying to access the same:
# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline -d
[snip..]
Reserved memory range
000000000e800000-000000002e7fffff (0)
Coredump memory ranges
0000000000000000-000000000e7fffff (0)
000000002e800000-000000003961ffff (0)
0000000039d40000-000000003ed2ffff (0)
000000003ed60000-000000003fbfffff (0)
0000001040000000-0000001ffbffffff (0)
0000002000000000-0000002ffbffffff (0)
0000009000000000-0000009ffbffffff (0)
000000a000000000-000000affbffffff (0)
4). So if we revert Ard's patch or just comment the fixing up of the
memory cap'ing passed to the crash kernel inside
'arch/arm64/mm/init.c' (see below):
static void __init fdt_enforce_memory_region(void)
{
struct memblock_region reg = {
.size = 0,
};
of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
if (reg.size)
//memblock_cap_memory_range(reg.base, reg.size); /*
comment this out */
}
5). Both the above temporary solutions fix the problem.
6). However exposing all System RAM regions to the crashkernel is not
advisable and may cause the crashkernel or some crashkernel drivers to
fail.
6a). I am trying an approach now, where the ACPI reclaim regions are
added to '/proc/iomem' separately as ACPI reclaim regions by the
kernel code and on the other hand the user-space 'kexec-tools' will
pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
dt node 'linux,usable-memory-range'
6b). The kernel code currently looks like the following:
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 30ad2f085d1f..867bdec7c692 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -206,6 +206,7 @@ static void __init request_standard_resources(void)
{
struct memblock_region *region;
struct resource *res;
+ phys_addr_t addr_start, addr_end;
kernel_code.start = __pa_symbol(_text);
kernel_code.end = __pa_symbol(__init_begin - 1);
@@ -218,9 +219,17 @@ static void __init request_standard_resources(void)
res->name = "reserved";
res->flags = IORESOURCE_MEM;
} else {
- res->name = "System RAM";
- res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+ addr_start =
__pfn_to_phys(memblock_region_reserved_base_pfn(region));
+ addr_end =
__pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1;
+ if ((efi_mem_type(addr_start) == EFI_ACPI_RECLAIM_MEMORY)
|| (efi_mem_type(addr_end) == EFI_ACPI_RECLAIM_MEMORY)) {
+ res->name = "ACPI reclaim region";
+ res->flags = IORESOURCE_MEM;
+ } else {
+ res->name = "System RAM";
+ res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+ }
}
+
res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
@@ -292,6 +301,7 @@ void __init setup_arch(char **cmdline_p)
request_standard_resources();
+ efi_memmap_unmap();
early_ioremap_reset();
if (acpi_disabled)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 80d1a885def5..a7c522eac640 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
reserve_regions();
efi_esrt_init();
- efi_memmap_unmap();
memblock_reserve(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
After this change the ACPI reclaim regions are properly recognized in
'/proc/iomem':
# cat /proc/iomem | grep -i ACPI
396c0000-3975ffff : ACPI reclaim region
39770000-397affff : ACPI reclaim region
398a0000-398bffff : ACPI reclaim region
6c). I am currently changing the 'kexec-tools' and will finish the
testing over the next few days.
I just wanted to know your opinion on this issue, so that I will be
able to propose a fix on the above lines.
Also Cc'ing kexec mailing list for more inputs on changes proposed to
kexec-tools.
Thanks,
Bhupesh
5 years, 12 months
[PATCHv2] kdump.sysconfig.ppc64(le): remove "root=" param from ppc64(le) 2nd kernel's command line
by Pingfan Liu
For ppc64(le), the default behavior of kexec always copy "root=" param,
but if dump target is ssh, there will no tools installed in kdump
rd, which help to mount root. As a result, kdump service will fail to
start. So explicitly disable the default behavior with --dt_no_old_root
option.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdump.sysconfig.ppc64 | 2 +-
kdump.sysconfig.ppc64le | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kdump.sysconfig.ppc64 b/kdump.sysconfig.ppc64
index be8e794..55a01cc 100644
--- a/kdump.sysconfig.ppc64
+++ b/kdump.sysconfig.ppc64
@@ -28,7 +28,7 @@ KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_di
#
# Example:
# KEXEC_ARGS="--elf32-core-headers"
-KEXEC_ARGS=""
+KEXEC_ARGS="--dt-no-old-root"
#Where to find the boot image
#KDUMP_BOOTDIR="/boot"
diff --git a/kdump.sysconfig.ppc64le b/kdump.sysconfig.ppc64le
index be8e794..55a01cc 100644
--- a/kdump.sysconfig.ppc64le
+++ b/kdump.sysconfig.ppc64le
@@ -28,7 +28,7 @@ KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_di
#
# Example:
# KEXEC_ARGS="--elf32-core-headers"
-KEXEC_ARGS=""
+KEXEC_ARGS="--dt-no-old-root"
#Where to find the boot image
#KDUMP_BOOTDIR="/boot"
--
2.7.4
6 years
[PATCH] kdump.sysconfig.ppc64(le): remove "root=" param from ppc64(le) 2nd kernel's command line
by Pingfan Liu
For ppc64(le), the default behavior of kexec always copy "root=" param,
but if dump target is ssh, there will no tools installed in kdump
rd, which help to mount root. As a result, kdump service will fail to
start. So explicitly disable the default behavior with --dt_no_old_root
option.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdump.sysconfig.ppc64 | 2 +-
kdump.sysconfig.ppc64le | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kdump.sysconfig.ppc64 b/kdump.sysconfig.ppc64
index be8e794..711a125 100644
--- a/kdump.sysconfig.ppc64
+++ b/kdump.sysconfig.ppc64
@@ -28,7 +28,7 @@ KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_di
#
# Example:
# KEXEC_ARGS="--elf32-core-headers"
-KEXEC_ARGS=""
+KEXEC_ARGS="--dt_no_old_root"
#Where to find the boot image
#KDUMP_BOOTDIR="/boot"
diff --git a/kdump.sysconfig.ppc64le b/kdump.sysconfig.ppc64le
index be8e794..711a125 100644
--- a/kdump.sysconfig.ppc64le
+++ b/kdump.sysconfig.ppc64le
@@ -28,7 +28,7 @@ KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_di
#
# Example:
# KEXEC_ARGS="--elf32-core-headers"
-KEXEC_ARGS=""
+KEXEC_ARGS="--dt_no_old_root"
#Where to find the boot image
#KDUMP_BOOTDIR="/boot"
--
2.7.4
6 years
[PATCH v3] kdumpctl: skip selinux-relabel for dracut_args --mount dump target
by Pingfan Liu
When using "dracut_args --mount" to specify dump target, e.g. nfs like:
path /
core_collector makedumpfile -d 31
dracut_args --mount "host:/path /var/crash nfs defaults"
kdump service should neither guarantees the correctness, nor relabels it.
For current code, since dracut_args dump targets are likely not mounted
so kdump service mistakenly relabel the rootfs, which is meanless and
takes very long time.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdumpctl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kdumpctl b/kdumpctl
index d4e0050..01db754 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -1013,6 +1013,9 @@ path_to_be_relabeled()
fi
fi
+ if is_mount_in_dracut_args; then
+ return;
+ fi
_path=$(get_save_path)
# if $_path is masked by other mount, we will not relabel it.
_rmnt=$(df $_mnt/$_path 2>/dev/null | tail -1 | awk '{ print $NF }')
--
2.7.4
6 years