On 2021/12/23 4:43, Borislav Petkov wrote:
> On Wed, Dec 22, 2021 at 09:08:04PM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> We want to make function reserve_crashkernel[_low](), which is implemented
> ^^
>
> Please use passive voice in your commit message: no "we" or "I", etc,
> and
On Wed, Dec 22, 2021 at 09:08:04PM +0800, Zhen Lei wrote:
> From: Chen Zhou
>
> We want to make function reserve_crashkernel[_low](), which is implemented
^^
Please use passive voice in your commit message: no "we" or "I", etc,
and describe your changes in imperative mood.
Also, pls read
From: Chen Zhou
For arm64, the behavior of crashkernel=X has been changed, which
tries low allocation in DMA zone and fall back to high allocation
if it fails.
We can also use "crashkernel=X,high" to select a high region above
DMA zone, which also tries to allocate at least 256M low memory in
From: Chen Zhou
Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
upper bound of high crash memory, use macros instead.
Besides, keep consistent with x86, use CRASH_ALIGN as the lower bound
of crash kernel
From: Chen Zhou
When reserving crashkernel in high memory, some low memory is reserved
for crash dump kernel devices and never mapped by the first kernel.
This memory range is advertised to crash dump kernel via DT property
under /chosen,
linux,usable-memory-range =
We reused the DT
Currently, we parse the "linux,usable-memory-range" property in
early_init_dt_scan_chosen(), to obtain the specified memory range of the
crash kernel. We then reserve the required memory after
early_init_dt_scan_memory() has identified all available physical memory.
Because the two pieces of code
From: Chen Zhou
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure because there is no low memory available
The parameters 'system_ram' and 'crash_base' is only needed by the case of
"crashkernel=X@[offset]". The argument list of parse_crashkernel_suffix()
can help prove this point.
Signed-off-by: Zhen Lei
---
kernel/crash_core.c | 20 ++--
1 file changed, 10 insertions(+), 10
From: Chen Zhou
Replace '(1ULL << 32)' with CRASH_ADDR_LOW_MAX to improve readability,
they are equal.
Signed-off-by: Chen Zhou
Signed-off-by: Zhen Lei
---
arch/x86/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c
From: Chen Zhou
Make the functions reserve_crashkernel[_low]() as generic. Since
reserve_crashkernel[_low]() implementations are quite similar on other
architectures as well, we can have more users of this later.
Signed-off-by: Chen Zhou
Co-developed-by: Zhen Lei
Signed-off-by: Zhen Lei
---
After commit adbc742bf786 ("x86, kdump: Change crashkernel_high/low= to
crashkernel=,high/low"), all kdump bootup parameters start with
"crashkernel=". Therefore, it is better for __parse_crashkernel() to use
it directly than for the caller to pass it. So the parameter 'name' can
be omitted.
Currently, parse_crashkernel_{high|low} is only referenced by
parse_crashkernel_in_order(), and they are in the same file. So make it
static, and move it into "#ifdef CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL".
Signed-off-by: Zhen Lei
---
include/linux/crash_core.h | 4
kernel/crash_core.c
From: Chen Zhou
There are multiple ARCHs that implement reserve_crashkernel(), all of them
are marked as static. Currently, we want to combine the implementations on
x86 and arm64 into one, and move it to public crash_core.c. To avoid
symbol conflicts on other platforms, add a new build option
Add comments to describe which bootup parameters are processed by the
code, and make comments close to the code being commented.
Signed-off-by: Zhen Lei
---
arch/x86/kernel/setup.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git
Currently, the parsing of "crashkernel=X,high" and the parsing of
"crashkernel=X,low" are not in the same function, but they are strongly
dependent, which affects readability. Use parse_crashkernel_in_order() to
bring them together.
In addition, the operation to ensure at least 256M low memory is
Currently, there are two possible combinations of configurations.
(1) crashkernel=X[@offset]
(2) crashkernel=X,high, with or without crashkernel=X,low
(1) has the highest priority, if it is configured correctly, (2) will be
ignored. Similarly, in combination (2), crashkernel=X,low is valid only
From: Chen Zhou
We will make the functions reserve_crashkernel() as generic, the
xen_pv_domain() check in reserve_crashkernel() is relevant only to
x86, the same as insert_resource() in reserve_crashkernel[_low]().
So move xen_pv_domain() check and insert_resource() to setup_arch()
to keep them
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure because there is no low memory available
for allocation.
Currently, only X86_64 requires that at least 256M low memory be reserved.
X86_32 does not have this requirement. So move all the code related to
reserve_crashkernel_low() into macro CONFIG_X86_64.
Signed-off-by: Zhen Lei
---
arch/x86/kernel/setup.c | 7 +--
1 file changed, 5 insertions(+),
From: Chen Zhou
We want to make function reserve_crashkernel[_low](), which is implemented
by X86, available to other architectures. It references macro CRASH_ALIGN
and will be moved to public crash_core.c. But the defined values of
CRASH_ALIGN may be different in different architectures. So
Hello Christoph.
On Tue, Dec 21, 2021 at 09:56:23AM +0100, Christoph Hellwig wrote:
> On Fri, Dec 17, 2021 at 11:38:27AM +, Hyeonggon Yoo wrote:
> > My understanding is any buffer requested from kmalloc (without
> > GFP_DMA/DMA32) can be used by device driver because it allocates
> >
On 22/12/2021 08:45, Dave Young wrote:
> Hi Guilherme,
>
> Thanks for you patch. Could you add kexec list for any following up
> patches? This could change kdump behavior so let's see if any comments
> from kexec list.
>
> Kudos for the lore+lei tool so that I can catch this by seeing this
>
Hi Guilherme,
Thanks for you patch. Could you add kexec list for any following up
patches? This could change kdump behavior so let's see if any comments
from kexec list.
Kudos for the lore+lei tool so that I can catch this by seeing this
coming into Andrews tree :)
On 11/09/21 at 05:28pm,
23 matches
Mail list logo
