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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5527663A.70402@linaro.org>
Date:	Fri, 10 Apr 2015 14:57:14 +0900
From:	AKASHI Takahiro <takahiro.akashi@...aro.org>
To:	Pratyush Anand <panand@...hat.com>, 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

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.

> 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.
# As I'm discussing with Mark about kvm issue, I'm holding off submitting it.

Thanks,
-Takahiro AKASHI


> ~Pratyush
>
>
>
> [1] https://github.com/pratyushanand/kexec-tools/commit/7dc38d587cb32d4522f6baf035d09eeaf71c5105
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ