On 01/25/24 at 05:12am, Michael Kelley wrote:
> From: Baoquan He Sent: Wednesday, January 24, 2024 8:10 PM
> >
> > On 01/24/24 at 11:02pm, Michael Kelley wrote:
> > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > > b/arch/x86/kernel/cpu/mshyperv.c
> > > > index 01fa06dd06b6..f8163a59026b 10
From: Baoquan He Sent: Thursday, January 25, 2024 1:17 AM
>
> On 01/25/24 at 05:12am, Michael Kelley wrote:
> > From: Baoquan He Sent: Wednesday, January 24, 2024
> 8:10 PM
> > >
> > > On 01/24/24 at 11:02pm, Michael Kelley wrote:
> > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > > > b
On Tue, Jan 16, 2024 at 06:14:31PM +0100, Jiri Bohac wrote:
> Since commit 29fe5067ed07 ("kexec: make -a the default")
> kexec tries the kexec_file_load syscall first and only falls back to
> kexec_load on
> selected error codes.
>
> This effectively breaks kexec on XEN, unless -c is pecified to
Thanks Mimi.
On 1/24/24 05:33, Mimi Zohar wrote:
Hi Tushar,
On Mon, 2024-01-22 at 10:37 -0800, Tushar Sugandhi wrote:
Missing from this and the other patch descriptions is the problem
description. Please refer to the section titled "Describe your changes" in
https://docs.kernel.org/process/
On 1/24/24 08:11, Mimi Zohar wrote:
On Mon, 2024-01-22 at 10:38 -0800, Tushar Sugandhi wrote:
ima_dump_measurement_list() is called during kexec 'load', which may
result in loss of IMA measurements during kexec soft reboot. It needs
to be called during kexec 'execute'.
The below changes nee
On 1/24/24 06:07, Mimi Zohar wrote:
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -121,6 +121,7 @@ void ima_add_kexec_buffer(struct kimage *image)
.buf_min = 0, .buf_max = ULONG_MAX,
.t
On 1/24/24 06:35, Mimi Zohar wrote:
On Mon, 2024-01-22 at 10:38 -0800, Tushar Sugandhi wrote:
The problem statement could be written as:
The amount of memory allocated at kexec load, even with the extra memory
allocated, might not be large enough for the entire measurement list. The
indeter
Hi,
Le 22/05/2018 à 10:23, Pingfan Liu a écrit :
> For kexec -p, the boot cpu can be not the cpu0, this causes the problem
> to alloc paca[]. In theory, there is no requirement to assign cpu's logical
> id as its present seq by device tree. But we have something like
> cpu_first_thread_sibling(),
The header files kexec.h is included twice in crash_reserve.c,
so one inclusion can be removed.
Signed-off-by: Yang Li
---
kernel/crash_reserve.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/crash_reserve.c b/kernel/crash_reserve.c
index bbb6c3cb00e4..db8bdf47a2c0 100644
--- a/kerne
t; CONFIG_CRASH_HOTPLUG=y
> CONFIG_CRASH_MAX_MEMORY_RANGES=8192
> # end of Kexec and crash features
> ---
>
> (3) unset CONFIG_CRASH_DUMP in case 2 and execute 'make olddefconfig':
> ----
> # Kexec and crash features
> CONFIG_KEXEC
On 01/25/24 at 09:55pm, Nathan Chancellor wrote:
..
> I am seeing a few build failures in my test matrix on next-20240125 that
> appear to be caused by this series although I have not bisected. Some
> reproduction steps:
Thanks for trying this, I have reproduced the linking failu
11 matches
Mail list logo