On 12/7/21 22:33, Andrew Morton wrote:
On Mon, 6 Dec 2021 22:03:59 -0600 John Donnelly
wrote:
On 12/6/21 9:16 PM, Baoquan He wrote:
Sorry, forgot adding x86 and x86/mm maintainers
Hi,
These commits need applied to Linux-5.15.0 (LTS) too since it has the
original regression :
1d659
On Mon, 6 Dec 2021 22:03:59 -0600 John Donnelly
wrote:
> On 12/6/21 9:16 PM, Baoquan He wrote:
> > Sorry, forgot adding x86 and x86/mm maintainers
>
> Hi,
>
>These commits need applied to Linux-5.15.0 (LTS) too since it has the
> original regression :
>
> 1d659236fb43 ("dma-pool: scale
See below, thanks, eric
On 12/1/21 06:59, Baoquan He wrote:
+ akpm
On 11/29/21 at 01:42pm, Eric DeVolder wrote:
Hi, see below.
eric
On 11/24/21 03:02, Baoquan He wrote:
Hi,
On 11/18/21 at 12:49pm, Eric DeVolder wrote:
..
This patchset introduces a generic crash hot un/plug handler that
This patch introduces a generic crash hot plug/unplug infrastructure
for CPU and memory changes. Upon CPU and memory changes, a generic
crash_hotplug_handler() obtains the appropriate lock, does some
important house keeping and then dispatches the hot plug/unplug event
to the architecture specific
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 utilizes
The pr_debug() intends to display the memsz member, but the
parameter is actually the bufsz member (which is already
displayed). Correct this to display memsz value.
Signed-off-by: Eric DeVolder
Acked-by: Baoquan He
---
arch/x86/kernel/crash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Two important changes to note:
The kexec_calculate_store_digests() changed to specifically EXCLUDE
the elfcorehdr segment from its list of segments to check.
This is an important change as it allows, in a hotplug environment,
for the elfcorehdr segment (which contains the list of CPUs and
memory r
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.
To update the elfcorehdr for x86_64, a new elfcorehdr must be
generated from the available CPUs and memory. The new elfcorehdr
is prepared into a buffer,
Support for CPU and memory hotplug for crash is controlled by the
CRASH_HOTPLUG configuration option, introduced by this patch.
The CRASH_HOTPLUG_ELFCOREHDR_SZ related configuration option is
also introduced with this patch.
Signed-off-by: Eric DeVolder
---
arch/x86/Kconfig | 26 +++
This change adds members to struct kimage to facilitate crash
hotplug support.
This change also defines crash hotplug events and associated
prototypes.
Signed-off-by: Eric DeVolder
---
include/linux/kexec.h | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git
On Tue, Dec 07, 2021 at 05:10:14PM +0100, Philipp Rudo wrote:
> Hi Michal,
>
> i finally had the time to take a closer look at the series. Except for
> the nit in patch 4 and my personal preference in patch 6 the code looks
> good to me.
>
> What I don't like are the commit messages on the first
Hi Michal,
On Thu, 25 Nov 2021 19:02:44 +0100
Michal Suchanek wrote:
> Multiple users of mod_check_sig check for the marker, then call
> mod_check_sig, extract signature length, and remove the signature.
>
> Put this code in one place together with mod_check_sig.
>
> Signed-off-by: Michal Such
Hi Michal,
On Thu, 25 Nov 2021 19:02:42 +0100
Michal Suchanek wrote:
> It is stripped by each caller separately.
>
> Signed-off-by: Michal Suchanek
> ---
> arch/powerpc/kexec/elf_64.c | 9 -
> arch/s390/kernel/machine_kexec_file.c | 9 -
> kernel/module.c
Hi Philipp,
Philipp Rudo writes:
>> diff --git a/kexec/arch/s390/kexec-image.c b/kexec/arch/s390/kexec-image.c
>> index dbeb689b830a..310d967ea331 100644
>> --- a/kexec/arch/s390/kexec-image.c
>> +++ b/kexec/arch/s390/kexec-image.c
>> @@ -72,6 +72,10 @@ int image_s390_load_file(int argc, char **
Hi Michal,
i finally had the time to take a closer look at the series. Except for
the nit in patch 4 and my personal preference in patch 6 the code looks
good to me.
What I don't like are the commit messages on the first commits. In my
opinion they are so short that they are almost useless. For e
Hi Philipp,
Philipp Rudo writes:
>> diff --git a/kexec/arch/s390/kexec-image.c b/kexec/arch/s390/kexec-image.c
>> index 3c24fdfe3c7c..7747d02399db 100644
>> --- a/kexec/arch/s390/kexec-image.c
>> +++ b/kexec/arch/s390/kexec-image.c
>> @@ -25,7 +25,7 @@
>> #include
>>
>> static uint64_t cras
Hi Sven,
makes absolutely sense to have this option. One problem though...
On Mon, 22 Nov 2021 08:14:01 +0100
Sven Schnelle wrote:
> --reuse-cmdline reads the command line of the currently
> running kernel from /proc/cmdline and uses that for the
> kernel that should be kexec'd.
>
> Signed-off
Hi Sven,
On Mon, 22 Nov 2021 08:13:59 +0100
Sven Schnelle wrote:
> Newer s390 kernels support a command line size longer than 896
> bytes. Such kernels contain a new member in the parameter area,
> which might be utilized by tools like kexec. Older kernels have
> the location initialized to zero
Hi Baoquan,
On Tue, 7 Dec 2021 11:34:46 +0800
Baoquan He wrote:
> On 12/06/21 at 12:17pm, Philipp Rudo wrote:
> > When booting with crashkernel= on the kernel command line a warning
> > similar to
> >
> > [0.038294] Kernel command line: ro console=ttyS0 crashkernel=256M
> > [0.038353] U
On 07.12.21 04:07, Baoquan He wrote:
> In some places of the current kernel, it assumes that dma zone must have
> managed pages if CONFIG_ZONE_DMA is enabled. While this is not always true.
> E.g in kdump kernel of x86_64, only low 1M is presented and locked down
> at very early stage of boot, so t
On Mon, Dec 06, 2021 at 03:07:15PM +, Matthew Wilcox wrote:
> > > What do you think to adding a generic copy_pfn_to_iter()? Not sure
> > > which APIs to use to implement it ... some architectures have weird
> > > requirements about which APIs can be used for what kinds of PFNs.
> >
> > Hmm.
On Tue, 7 Dec 2021, Baoquan He wrote:
> into ZONE_DMA32 by default. The zone DMA covering low 16M is used to
> take care of antique ISA devices. In fact, on 64bit system, it rarely
> need ZONE_DMA (which is low 16M) to support almost extinct ISA devices.
> However, some components treat DMA as a g
22 matches
Mail list logo
