linux-kernel - Re: [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 10 Apr 2015 12:05:58 +0530
From:	Pratyush Anand <panand@...hat.com>
To:	AKASHI Takahiro <takahiro.akashi@...aro.org>,
	catalin.marinas@....com, will.deacon@....com, vgoyal@...hat.com,
	hbabus@...ibm.com
CC:	linaro-kernel@...ts.linaro.org, geoff@...radead.org,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	broonie@...nel.org, david.griego@...aro.org,
	linux-arm-kernel@...ts.infradead.org,
	Dave Young <dyoung@...hat.com>
Subject: Re: [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel



On Friday 10 April 2015 11:27 AM, AKASHI Takahiro wrote:
> Hi Pratyush,
>
> On 04/09/2015 10:09 PM, Pratyush Anand wrote:
>> Hi Takahiro,
>>
>> On Thursday 26 March 2015 01:58 PM, AKASHI Takahiro wrote:
>>> Crash dump kernel will access memory regions in system kernel via
>>> copy_oldmem_page(), which reads a page with ioremap'ing it assuming that
>>> such pages are not part of main memory of crash dump kernel.
>>> This is true under non-UEFI environment because kexec-tools modifies
>>> a device tree adding "usablemem" attributes to memory sections.
>>> Under UEFI, however, this is not true because UEFI remove memory
>>> sections
>>> in a device tree and export all the memory regions, even though they
>>> belong
>>> to system kernel.
>>>
>>> So we should add "mem=X[MG]" boot parameter to limit the meory size and
>>> avoid hitting the following assertion in ioremap():
>>>     if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>>>         return NULL;
>>
>> Well I am using your updated kexec-tool which has support of automatic
>> addition of "mem=" parameter. I found that this
>> warning is still appearing and therefore another error about "Kdump:
>> vmcore not initialized".
>>
>> Memory address for which ioremap failed was almost at the top of
>> crash_reserved_mem. So I modified kexec-tool [1] to
>> accept user specific mem= parameter with a value lesser than physical
>> location which was being remapped, however still
>> the warning was there.
>>
>> Further I noticed that there is no reserved memblock with nonzero
>> memblock_region->size when early_mem ->
>> memblock_enforce_memory_limit is called. Therefore this mem= param is
>> not limiting memory location in my case.
>
> On crash dump kernel? Sounds strange.
> Can you send me the followings for both 1st kernel and crash dump kernel?
> (add memblock_debug to cmd line for verbose messages)
>
> - boot log (dmesg)
> - cat /proc/iomem
>
> sending them in a private mail is fine.

OK.

>
>> I was just wondering, why do not we use ioremap_cache instead of
>> ioremap in copy_oldmem_page?
>
> Good point.
> My next version of kdump patch uses ioremap_cache() for another reason.

Thanks that you have already changed it. I am using ioremap_cache and I 
am able to get /proc/vmcore :)
ioremap allocates VAs with memory attribute DEVICE which might not be 
correct for RAM area.ioremap_cache is using memory attribute NORMAL 
which seems more logical for RAM areas.

> # As I'm discussing with Mark about kvm issue, I'm holding off
> submitting it.
>

I  am using one more modification on top of your patches for finding 
crashkernel address automatically. If that seems fine to you then may be 
I can send you that patch and you can add that in your next rev.

Author: Pratyush Anand <panand@...hat.com>
Date:   Tue Apr 7 08:14:55 2015 +0530

     arm64/kdump: Find free area for crash kernel memory

     If crashkernel=X@0 is passed to the kernel then this patch will find
     free memory area of size X for crash kernel.

     Signed-off-by: Pratyush Anand <panand@...hat.com>

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 94694897beea..90b0b9d138f6 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -368,10 +368,18 @@ static void __init reserve_crashkernel(void)
         if (ret)
                 return;

-       ret = memblock_reserve(crash_base, crash_size);
-       if (ret < 0) {
+       /* 0 means: find the address automatically */
+       if (crash_base <= 0) {
+               crash_base = memblock_alloc(crash_size, 2 << 20);
+
+               if (!crash_base) {
+                       pr_warn("Could not find free memory for 
crashkernel\n");
+                       return;
+               }
+
+       } else if (memblock_reserve(crash_base, crash_size) < 0) {
                 pr_warn("crashkernel reservation failed - memory is in 
use (0x%lx)\n",
-                       (unsigned long)crash_base);
+                               (unsigned long)crash_base);
                 return;
         }

~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/