This introduces the crash_hotplug attribute for memory and CPUs
for use by userspace. This change directly facilitates the udev
rule for managing userspace re-loading of the crash kernel upon
hot un/plug changes.
For memory, this changeset introduces the crash_hotplug attribute
to the
CPU and memory change notifications are received in order to
regenerate the elfcorehdr.
To support cpu hotplug, a callback is registered to capture the
CPUHP_AP_ONLINE_DYN online and offline events via
cpuhp_setup_state_nocalls().
To support memory hotplug, a notifier is registered to capture
For x86_64, when CPU or memory is hot un/plugged, the crash
elfcorehdr, which describes the CPUs and memory in the system,
must also be updated.
When loading the crash kernel via kexec_load or kexec_file_load,
the elfcorehdr is identified at run time in
crash_core:handle_hotplug_event().
To
>From within crash_prepare_elf64_headers() there is a need to
reference the struct kimage hotplug members. As such, this
change passes the struct kimage as a parameter to the
crash_prepare_elf64_headers(). The hotplug members are added
in "crash: add generic infrastructure for crash hotplug
Due to use of CPUHP_AP_ONLINE_DYN, upon CPU unplug, the CPU is
still in the for_each_present_cpu() list when within the
handle_hotplug_event(). Thus the CPU must be explicitly excluded
when building the new list of CPUs.
This change identifies in handle_hotplug_event() the CPU to be
excluded, and
When the kdump service is loaded, if a CPU or memory is hot
un/plugged, the crash elfcorehdr (for x86), which describes the CPUs
and memory in the system, must also be updated, else the resulting
vmcore is inaccurate (eg. missing either CPU context or memory
regions).
The current solution
When a crash kernel is loaded via the kexec_file_load syscall, the
kernel places the various segments (ie crash kernel, crash initrd,
boot_params, elfcorehdr, purgatory, etc) in memory. For those
architectures that utilize purgatory, a hash digest of the segments
is calculated for integrity
At the outcome of this patch set, the crash_prepare_elf64_headers()
is utilized on both the kexec_file_load and kexec_load paths. As
such, need to move this function out of kexec_file.c and into a
common location crash_core.c.
No functionality change.
Signed-off-by: Eric DeVolder
---
Andrew Morton writes:
> On Mon, 13 Jun 2022 14:59:44 -0700 Stephen Brennan
> wrote:
>> >> Related discussion around the BTF side of this:
>> >> https://lore.kernel.org/bpf/586a6288-704a-f7a7-b256-e18a67592...@oracle.com/T/#u
>> >>
>> >> Some work-in-progress branches using this feature:
>> >>
On Mon, 13 Jun 2022 14:59:44 -0700 Stephen Brennan
wrote:
> >> Related discussion around the BTF side of this:
> >> https://lore.kernel.org/bpf/586a6288-704a-f7a7-b256-e18a67592...@oracle.com/T/#u
> >>
> >> Some work-in-progress branches using this feature:
> >>
Andrew Morton writes:
> On Mon, 16 May 2022 17:05:06 -0700 Stephen Brennan
> wrote:
>
>> The kernel can be configured to contain a lot of introspection or
>> debugging information built-in, such as ORC for unwinding stack traces,
>> BTF for type information, and of course kallsyms. Debuggers
On Mon, 16 May 2022 17:05:06 -0700 Stephen Brennan
wrote:
> The kernel can be configured to contain a lot of introspection or
> debugging information built-in, such as ORC for unwinding stack traces,
> BTF for type information, and of course kallsyms. Debuggers could use
> this information to
On Mon, 2022-06-13 at 10:30 +, Jonathan McDowell wrote:
> On kexec file load Integrity Measurement Architecture (IMA) subsystem
> may verify the IMA signature of the kernel and initramfs, and measure
> it. The command line parameters passed to the kernel in the kexec call
> may also be
Hi Andrew,
Baoquan He writes:
> On 05/23/22 at 11:00am, Stephen Brennan wrote:
>> Do you know which tree this patch will go through?
>
> I would like to ask Andrew to help check and pick this if no concern.
Just wanted to check if you would be willing to take a look at this
series and possibly
14 matches
Mail list logo
