On 08/12/23 at 07:11am, Baoquan He wrote:
> On 08/11/23 at 01:27pm, Pandey, Radhey Shyam wrote:
> > > -Original Message-
> > > From: b...@redhat.com
> > > Sent: Wednesday, August 9, 2023 7:42 AM
> > > To: Pandey, Radhey Shyam ;
> > > pi...@redhat.com
> > > Cc: kexec@lists.infradead.org;
On 08/11/23 at 01:27pm, Pandey, Radhey Shyam wrote:
> > -Original Message-
> > From: b...@redhat.com
> > Sent: Wednesday, August 9, 2023 7:42 AM
> > To: Pandey, Radhey Shyam ;
> > pi...@redhat.com
> > Cc: kexec@lists.infradead.org; linux-ker...@vger.kernel.org
> > Subject: Re: kexec
On 8/11/23 11:57, Tushar Sugandhi wrote:
[1]
https://patchwork.kernel.org/project/linux-integrity/cover/20230801181917.8535-1-tusha...@linux.microsoft.com/
The shards should will need to be written into some sort of standard location
or a config file needs to
be defined, so that
To support crash hotplug, a mechanism is needed to update the crash
elfcorehdr upon CPU or memory changes (eg. hot un/plug or off/
onlining). The crash elfcorehdr describes the CPUs and memory to
be written into the vmcore.
To track CPU changes, callbacks are registered with the cpuhp
mechanism
This series is dependent upon "refactor Kconfig to consolidate
KEXEC and CRASH options".
https://lore.kernel.org/lkml/20230712161545.87870-1-eric.devol...@oracle.com/
Once the kdump service is loaded, if changes to CPUs or memory occur,
either by hot un/plug or off/onlining, the crash elfcorehdr
crash_prepare_elf64_headers() writes into the elfcorehdr an ELF
PT_NOTE for all possible CPUs. As such, subsequent changes to CPUs
(ie. hot un/plug, online/offline) do not need to rewrite the elfcorehdr.
The kimage->file_mode term covers kdump images loaded via the
kexec_file_load() syscall.
The function crash_prepare_elf64_headers() generates the elfcorehdr
which describes the CPUs and memory in the system for the crash kernel.
In particular, it writes out ELF PT_NOTEs for memory regions and the
CPUs in the system.
With respect to the CPUs, the current implementation utilizes
When CPU or memory is hot un/plugged, or off/onlined, the crash
elfcorehdr, which describes the CPUs and memory in the system,
must also be updated.
A new elfcorehdr is generated from the available CPUs and memory
and replaces the existing elfcorehdr. The segment containing the
elfcorehdr is
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
Introduce the crash_hotplug attribute for memory and CPUs for
use by userspace. These attributes directly facilitate the udev
rule for managing userspace re-loading of the crash kernel upon
hot un/plug changes.
For memory, expose the crash_hotplug attribute to the
/sys/devices/system/memory
The crash hotplug support leans on the work for the kexec_file_load()
syscall. To also support the kexec_load() syscall, a few bits of code
need to be move outside of CONFIG_KEXEC_FILE. As such, these bits are
moved out of kexec_file.c and into a common location crash_core.c.
No functionality
The hotplug support for kexec_load() requires changes to the
userspace kexec-tools and a little extra help from the kernel.
Given a kdump capture kernel loaded via kexec_load(), and a
subsequent hotplug event, the crash hotplug handler finds the
elfcorehdr and rewrites it to reflect the hotplug
On 8/10/23 07:12, Stefan Berger wrote:
On 8/9/23 21:15, Tushar Sugandhi wrote:
Thanks a lot Stefan for looking into this proposal,
and providing your feedback. We really appreciate it.
On 8/7/23 15:49, Stefan Berger wrote:
On 8/1/23 17:21, James Bottomley wrote:
On Tue, 2023-08-01 at
On 8/10/23 04:43, James Bottomley wrote:
On Wed, 2023-08-09 at 21:43 -0700, Tushar Sugandhi wrote:
On 8/8/23 14:41, James Bottomley wrote:
On Tue, 2023-08-08 at 16:09 -0400, Stefan Berger wrote:
[...]
at this point doesn't seem necessary since one presumably can
verify the log and PCR
> -Original Message-
> From: b...@redhat.com
> Sent: Wednesday, August 9, 2023 7:42 AM
> To: Pandey, Radhey Shyam ;
> pi...@redhat.com
> Cc: kexec@lists.infradead.org; linux-ker...@vger.kernel.org
> Subject: Re: kexec reports "Cannot get kernel _text symbol address" on
> arm64 platform
>
Hi Sush, Tushar,
On Tue, 2023-08-01 at 12:12 -0700, Sush Shringarputale wrote:
>
> | A. Problem Statement |
>
> Depending on the IMA policy, the IMA log can consume a lot of
On Thu, Aug 10, 2023 at 08:09:27AM +0800, Ming Lei wrote:
> 1) some archs support 'nr_cpus=1' for kdump kernel, which is fine, since
> num_possible_cpus becomes 1.
>
> 2) some archs do not support 'nr_cpus=1', and have to rely on
> 'max_cpus=1', so num_possible_cpus isn't changed, and kernel just
Now we use "memeory::linux,usable-memory" to indicate the available
memory for the crash kernel.
While booting with UEFI, the crash kernel would use efi.memmap to
re-populate memblock and then first kernel's memory would be corrputed.
Consequently, the /proc/vmcore file failed to create in my
Use local `elf.h` instead of `linux/elf.h` to fix this build error:
```
kexec/arch/riscv/crashdump-riscv.c:17:13: error: ‘EM_RISCV’ undeclared here
(not in a function); did you mean ‘EM_CRIS’?
.machine = EM_RISCV,
^~~~
EM_CRIS
```
Signed-off-by: Song Shuai
---
On 10/08/23 8:31 am, Baoquan He wrote:
On 08/10/23 at 10:06am, Ming Lei wrote:
On Thu, Aug 10, 2023 at 09:18:27AM +0800, Baoquan He wrote:
On 08/10/23 at 08:09am, Ming Lei wrote:
On Wed, Aug 09, 2023 at 03:44:01PM +0200, Christoph Hellwig wrote:
I'm starting to sound like a broken record,
Hi all,
I am planning to release kexec-tools v2.0.27 in the next two weeks
to roughly coincide with the release of the v6.5 kernel.
I would like to ask interested parties to send any patches they would like
included in v2.0.27 within one week so they can be considered for inclusion
in an rc
On Thu, Aug 03, 2023 at 10:41:47AM +0800, Pingfan Liu wrote:
> From: root
>
> As more complicated capsule kernel format occurs like zboot, where the
> compressed kernel is stored as a payload. The straight forward
> decompression can not meet the demand.
>
> As the first step, on aarch64,
22 matches
Mail list logo
