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: <50FEB620.3020805@zytor.com>
Date:	Tue, 22 Jan 2013 09:54:08 -0600
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Thomas Renninger <trenn@...e.de>
CC:	yinghai@...nel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
	kexec@...ts.infradead.org, vgoyal@...hat.com, horms@...ge.net.au
Subject: Re: [PATCH 2/2] x86 e820: Introduce memmap=resetusablemap for kdump
 usage

On 01/22/2013 09:20 AM, Thomas Renninger wrote:
> From: Yinghai Lu <yinghai@...nel.org>
> 
> kdump voided the whole original e820 map and half way made
> it up via memmap= options passed via kdump boot params again.
> 
> But this is conceptionally wrong. The whole original memory ranges
> which are declared reserved, ACPI data/nvs or however are not usable
> must stay the same and get honored by the kdump kernel.
> 
> Therefore memmap=resetusablemap gets introduced.
> kdump passes this one and only the usable e820 ranges are removed.
> kdump passes the usable ranges to use via memmap=x@y parameter(s).
> The not usable e820 ranges are preserved.
> 
> This for example fixes mmconf (extended PCI config access) and
> possibly other kernel parts which rely on remapped memory to be
> in reserved or ACPI (data/nvs) declared e820 memory areas.
> 
> Tested-by: Thomas Renninger <trenn@...e.de>
> Reviewed-by: Thomas Renninger <trenn@...e.de>
> Signed-off-by: Thomas Renninger <trenn@...e.de>

Tested-by: and Reviewed-by: are rather redundant with Signed-off-by:.
Also, you should have a Signed-off-by: from the author (Yinghai).

However, when thinking about it this really doesn't seem to be the right
interface, either.  Something like "memmap=reserveram" which turns all
RAM areas into reserved areas, which can then be overridden by memmap=
options would make more sense.

Even more sense would be to pass the modified memmap to kexec...

	-hpa


--
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