[PATCH v22 1/8] arm64: kdump: reserve memory for crash dump kernel

On Tue, Jul 19, 2016 at 02:27:54PM +0100, Mark Rutland wrote:

On Tue, Jul 19, 2016 at 08:48:57AM -0400, Mark Salter wrote:

quoted

On Tue, 2016-07-19 at 18:41 +0800, Dennis Chen wrote:

quoted

On Tue, Jul 19, 2016 at 07:28:16PM +0900, AKASHI Takahiro wrote:

quoted

On Tue, Jul 19, 2016 at 05:39:07PM +0800, Dennis Chen wrote:

quoted

On Tue, Jul 12, 2016 at 02:05:07PM +0900, AKASHI Takahiro wrote:

quoted

+/*
+ * reserve_crashkernel() - reserves memory for crash kernel
+ *
+ * This function reserves memory area given in "crashkernel=" kernel command
+ * line parameter. The memory reserved is used by dump capture kernel when
+ * primary kernel is crashing.
+ */
+static void __init reserve_crashkernel(void)
+{
+??????????int ret;
+
+??????????ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
+??????????????????????????????????????????????????????????&crash_size, &crash_base);
+??????????/* no crashkernel= or invalid value specified */
+??????????if (ret || !crash_size)
+??????????????????????????return;
+
+??????????if (crash_base == 0) {
+??????????????????????????/* Current arm64 boot protocol requires 2MB alignment */
+??????????????????????????crash_base = memblock_find_in_range(0,
+??????????????????????????????????????????????????????????MEMBLOCK_ALLOC_ACCESSIBLE, crash_size, SZ_2M);
+??????????????????????????if (crash_base == 0) {
+??????????????????????????????????????????pr_warn("Unable to allocate crashkernel (size:%llx)\n",
+??????????????????????????????????????????????????????????crash_size);
+??????????????????????????????????????????return;
+??????????????????????????}
+??????????????????????????memblock_reserve(crash_base, crash_size);

I am not pretty sure the context here, but
can we use below code piece instead of the above lines?
????????????????if (crash_base == 0)
????????????????????????????????memblock_alloc(crash_size, SZ_2M);

Either would be fine here.

Hello AKASHI, maybe you can succeed to find the base with memblock_find_in_range(),??
but that doesn't mean you will also succeed to reserve them with memblock_reserve followed.

We avoid memblock_alloc() here because it panics on failure. This could happen
if user asks for an unusually large crashkernel size. Better to print a message
and keep booting. Checking the return value of memblock_reserve() seems like a
good thing to do though.

Another option would be to add a memblock_try_alloc() function to the
memblock API, which in case of failure returns 0 rather than triggering
a panic(). We'd still have to check the return value, but all the
memblock manipulation would be in one place.

It looks like adding that is fairly simple:

phys_addr_t __init memblock_try_alloc(phys_addr_t size, phys_addr_t align)
{
	return __memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
}

Apart form this issue, I found that the kernel can panic, if the memory
for crash dump kernel is allocated above 32-bits, due to a failure
of alloc_bootmem_low() in request_standard_resources().
(In addition, dma_contiguous_reserve() will also fail.)

So I'd like to change the code to:
        if (crash_base == 0) {
                crash_base = memblock_find_in_range(0,
                                IS_ENABLED(CONFIG_ZONE_DMA) ?
                                        ARCH_LOW_ADDRESS_LIMIT :
                                        MEMBLOCK_ALLOC_ACCESSIBLE,
                                crash_size, SZ_2M);
        ...

Does this make sense?

Thanks,
-Takahiro AKASHI

Thanks,
Mark.