On 01/05/24 at 08:49am, Andrew Morton wrote:
> On Fri, 29 Dec 2023 16:02:13 +0800 Huacai Chen wrote:
>
> > In /proc/iomem, sub-regions should be inserted after their parent,
> > otherwise the insertion of parent resource fails. But after generic
> > crashkernel reservation applied, in both RISC-V
On Sat, 2024-01-06 at 03:59 +0300, kirill.shute...@linux.intel.com
wrote:
> But why? There's no concurrency at this point. Interrupts are
> disabled and
> only one CPU is active. Nobody can touch the memory relevant for the
> PTE.
Oh, right, sorry. I had thought there could be other CPUs active at
On Fri, Jan 05, 2024 at 07:38:48PM +, Edgecombe, Rick P wrote:
> The break apart looks good.
>
> On Sat, 2023-12-23 at 02:52 +0300, Kirill A. Shutemov wrote:
> > + while (addr < end) {
> > + unsigned long size;
> > + unsigned int level;
> > + pte
On 12/20/23 12:41, Mimi Zohar wrote:
On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
There could be a potential mismatch between IMA measurements and TPM PCR
quotes caused by the indeterminate interval between kexec 'load' and
'execute'. Memory allocated at kexec 'load' for IMA log
On 12/20/23 12:15, Mimi Zohar wrote:
Hi Tushar,
The Subject line should include the word "extra". The use of the
extra memory isn't limited to the measurements between the kexec load
and exec. Additional records could be added as a result of the kexec
load itself. Let's simplify the title
On 12/20/23 12:44, Mimi Zohar wrote:
On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
If the new measurements are added to the IMA log while it is being
being copied to the kexec buffer during kexec 'execute', it can miss
copying those new measurements to the kexec buffer, and the bu
Thanks Mimi for the feedback on V3.
Sorry for the late response, I was on vacation during the holidays.
Responses inline.
Happy new year! :)
On 12/20/23 08:13, Mimi Zohar wrote:
On Fri, 2023-12-15 at 17:07 -0800, Tushar Sugandhi wrote:
Refactor ima_dump_measurement_list() to move the memory
The break apart looks good.
On Sat, 2023-12-23 at 02:52 +0300, Kirill A. Shutemov wrote:
> + while (addr < end) {
> + unsigned long size;
> + unsigned int level;
> + pte_t *pte;
> +
> + pte = lookup_address(addr, &level);
> +
On Fri, 29 Dec 2023 16:02:13 +0800 Huacai Chen wrote:
> In /proc/iomem, sub-regions should be inserted after their parent,
> otherwise the insertion of parent resource fails. But after generic
> crashkernel reservation applied, in both RISC-V and ARM64 (LoongArch
> will also use generic reservati
By splitting CRASH_CORE into CRASH_RESERVE and VMCORE_INFO, and cleaning
up the dependency of FA_DMUMP on CRASH_DUMP, now we can rearrange CRASH_DUMP
to depend on KEXEC_CORE, and select CRASH_RESERVE and VMCORE_INFO.
KEXEC_CORE won't select CRASH_RESERVE and VMCORE_INFO any more because
KEXEC_CO
In kdump kernel, /proc/vmcore is an elf file which maps the crashed kernel's
read_from_oldmemmemory content. Its elf header is constructed in 1st kernel and
passed
to kdump kernel via elfcorehdr_addr. Config CRASH_DUMP enables the code
of 1st kernel's old memory accessing in different architecture
Both kdump and fa_dump of ppc rely on crashkernel reservation. Move the
relevant codes into separate files:
crash_reserve.c, include/linux/crash_reserve.h.
And also add config item CRASH_RESERVE to control its enabling of the
codes. And update confit items which has relationship with crashkernel
r
Now only vmcoreinfo handling related code is in crash_core.c, so do the
renaming as follows:
kernel/{crash_core.c => vmcore_info.c}
arch/xxx/kernel/{crash_core.c => vmcore_info.c}
include/linux/{crash_core.h => vmcore_info.h}
CONFIG_CRASH_CORE => CONFIG_VMCORE_INFO
And also update the old if
Motivation:
=
Previously, LKP reported a building error. When investigating, it can't
be resolved reasonablly with the present messy kdump config items.
https://lore.kernel.org/oe-kbuild-all/202312182200.ka7mzifq-...@intel.com/
The kdump (crash dumping) related config items could cau
In commit 6f991cc363a3 ("crash: move a few code bits to setup support
of crash hotplug"), some elfcorehdr processing codes were moved to
kernel/crash_core.c so that they can be shared by kexec_load and
kexec_file_load interface. And later in commit 247262756121 ("crash: add
generic infrastructure f
15 matches
Mail list logo
